Category Archives: Security engineering

Bad security, good security, case studies, lessons learned

Three Paper Thursday: Vēnī, Vīdī, Vote-y – Election Security

With the recent quadrennial instantiation of the US presidential election, discussions of election security have predictably resurged across much of the world. Indeed, news cycles in the US, UK, and EU abound with talking points surrounding the security of elections. In light of this context, we will use this week’s Three Paper Thursday to shed light on the technical challenges, solutions, and opportunities in designing secure election systems.

This post will focus on the technical security of election systems. That said, the topic of voter manipulation techniques such as disinformation campaigns, although out of scope here, is also an open area of research.

At first glance, voting may not seem like a challenging problem. If we are to consider a simple majority vote, surely a group of young schoolchildren could reach a consensus in minutes via hand-raising. Striving for more efficient vote tallying, though, perhaps we may opt to follow the IETF in consensus through humming. As we seek a solution that can scale to large numbers of voters, practical limitations will force us to select a multi-location, asynchronous process. Whether we choose in-person polling stations or mail-in voting, challenges quickly develop: how do we know a particular vote was counted, its contents kept secret, and the final tally correct?

National Academies of Sciences, Engineering, and Medicine (U.S.), Ed., Securing the vote: protecting American democracy, The National Academies Press (2018)

The first paper is particularly prominent due to its unified, no-nonsense, and thorough analysis. The report is specific to the United States, but its key themes apply generally. Written in response to accusations of international interference in the US 2016 presidential election, the National Academies provide 41 recommendations to strengthen the US election system.

These recommendations are extremely straightforward, and as such a reminder that adversaries most often penetrate large systems by targeting the “weakest link.” Among other things, the authors recommend creating standardized ballot data formats, regularly validating voter registration lists, evaluating the accessibility of ballot formats, ensuring access to absentee ballots, conducting appropriate audits, and providing adequate funding for elections.

It’s important to get the basics right. While there are many complex, stimulating proposals that utilize cutting-edge algorithms, cryptography, and distributed systems techniques to strengthen elections, many of these proposals are moot if the basic logistics are mishandled.

Some of these low-tech recommendations are, to the surprise of many passionate technologists, quite common among election security specialists. For example, requiring a paper ballot trail and avoiding internet voting based on current technology is also cited in our next paper.

Matthew Bernhard et al., Public Evidence from Secret Ballots, arXiv:1707.08619 (2017)

Governance aside, the second paper offers a comprehensive survey of the key technical challenges in election security and common tools used to solve them. The paper motivates the difficulty of election systems by attesting that all actors involved in an election are mutually distrustful, meaningful election results require evidence, and voters require ballot secrecy.

Ballot secrecy is more than a nicety; it is key to a properly functioning election system. Implemented correctly, ballot secrecy prevents voter coercion. If a voter’s ballot is not secret, or indeed if there is any way a voter can post-facto prove the casting a certain vote, malicious actors may pressure the voter to provide proof that they voted as directed. This can be insidiously difficult to prevent if not considered thoroughly.

Bernhard et al. discuss risk-limiting audits (RLAs) as an efficient yet powerful way to limit uncertainty in election results. By sampling and recounting a subset of votes, RLAs enable the use of statistical methods to increase confidence in a correct ballot count. Employed properly, RLAs can enable the high-probability validation of election tallies with effort inversely proportional to the expected margin. RLAs are now being used in real-world elections, and many RLA techniques exist in practice. 

Refreshingly, this paper establishes that blockchain-based voting is a bad idea. Blockchains inherently lack a central authority, so enforcing election rules would be a challenge. Furthermore, a computationally powerful adversary could control which votes get counted.

The paper also discusses high-level cryptographic tools that can be useful in elections. This leads us to our third and final paper.

Josh Benaloh, ElectionGuard Specification v0.95, Microsoft GitHub (2020)

Our final paper is slightly different from the others in this series; it’s a snapshot of a formal specification that is actively being developed, largely based on the author’s 1996 Yale doctoral thesis.

The specification describes ElectionGuard, a system being built by Microsoft to enable verifiable election results (disclaimer: the author of this post holds a Microsoft affiliation). It uses a combination of exponential ElGamal additively-homomorphic encryption, zero knowledge proofs, and Shamir’s secret sharing to conduct publicly-verifiable, secret-ballot elections.

When a voter casts a ballot, they are given a tracking code which can be used to verify the counting of the ballot’s votes via cryptographic proofs published with the final tally. Voters can achieve high confidence that their ballot represents a proper encryption of their desired votes by optionally spoiling an unlimited number of ballots triggering a decryption of the spoiled ballot at the time of voting. Encrypted ballots are homomorphically tallied in encrypted form by the election authorities, and the number of authorities that participate in tallying must meet the threshold set for the election to protect against malicious authorities.

The specification does not require that the system be used for exclusively internet-based or polling station-based elections; rather it is a framework for users to consume as they wish. Indeed, one of the draws to ElectionGuard is that it does not mandate a specific UI, ballot marking device, or even API. This flexibility allows election authorities to leverage the system in the manner that best fits their jurisdiction. The open source implementation can be found on GitHub.

There are many pieces of voting software available, but ElectionGuard is the new kid on the block that addresses many of the concerns raised in our earlier papers.

Key Themes

Designing secure election systems is difficult.

Often, election systems fall short on the basics; improper voting lists, postage issues, and poorly formatted ballots can disrupt elections as much as some adversaries. Ensuring that the foundational components of an election are handled well currently involves seemingly mundane but important things such as paper ballot trails, chains of custody, and voter ID verification.

High-tech election proposals are not new; indeed key insights into the use of cryptographic techniques in elections were being discussed in the academic literature well over two decades ago. That said, in recent years there has been an ostensibly increased investment in implementing cryptographic election systems, and although there remain many problems to be solved the future in this area looks promising.

Three Paper Thursday: Attacking Machine Vision Models In Real Life

This is a guest post by Alex Shepherd.

There is a growing body of research literature concerning the potential threat of physical-world adversarial attacks against machine-vision models. By applying adversarial perturbations to physical objects, machine-vision models may be vulnerable to images containing these perturbed objects, resulting in an increased risk of misclassification. The potential impacts could be significant and have been identified as risk areas for autonomous vehicles and military UAVs.

For this Three Paper Thursday, we examine the following papers exploring the potential threat of physical-world adversarial attacks, with a focus on the impact for autonomous vehicles.

Alexey Kurakin, Ian Goodfellow, and Samy Bengio. Adversarial examples in the physical world, arXiv:1607.02533 (2016)

In this seminal paper, Kurakin et al. report their findings of an experiment conducted using adversarial images taken from a phone camera as input for a pre-trained ImageNet Inceptionv3 image classification model. Methodology was based on a white-box threat model, with adversarial images crafted from the ImageNet validation dataset using the Inceptionv3 model.
Continue reading Three Paper Thursday: Attacking Machine Vision Models In Real Life

SRI and Cambridge release CHERI software stack for Arm Morello

For the last ten years, SRI International and the University of Cambridge have been working to develop CHERI (Capability Hardware Enhanced RISC Instructions), a DARPA-sponsored processor architecture security technology implementing efficient fine-grained memory protection and scalable software compartmentalization. You can learn more about CHERI in our Introduction to CHERI technical report, which describes the architectural, microarchitectural, formal modelling, and software approaches we have created.

For the last six of those years, we have been collaborating closely with Arm to create an adaptation of CHERI to the ARMv8-A architecture, which is slated to appear in Arm’s prototype Morello processor, System-on-Chip (SoC), and board in Q1 2022. Richard Grisenthwaite, Arm’s Principal Architect, announced this joint work at the UKRI Digital Security by Design (DSbD) workshop in September 2019. DSbD is a UKRI / Industrial Strategy Challenge Fund (ISCF) research programme contributing to the creation of the Morello board, and CHERI is the Digital Security by Design Technology that underlies the programme. Our collaboration with Arm has been an enormously exciting experience, involving daily engagement Arm’s architects, microarchitects, and software designers. This included hosting several members of Arm’s team at our lab in Cambridge over multiple years, as we brought together our long-term research on architectural and software security with their experience in industrial architecture, processor designs, and transition.

Today, Richard Grisenthwaite announced that Arm is releasing their first simulator for the Morello architecture, the Morello FVP (Fixed Virtual Platform), and also an open-source software stack that includes their adaptation of our CHERI Clang/LLVM to Morello and early work on Morello support for Android. These build on the Morello architecture specification, released in late September 2020. SRI and Cambridge are releasing a first developer preview release of the CHERI reference software stack ported to Morello – intended to show a rich integration of CHERI into a contemporary OS design, as well as demonstration applications. This stack includes CheriBSD, a BSD-licensed reference design and open-source applications adapted to CHERI including OpenSSH, nginx, and WebKit.

For this first developer preview release, we have focused on bringing CHERI C/C++ memory protection to Morello. Our CheriABI process environment, which allows the full UNIX userspace to run with fine-grained spatial memory safety, is fully functional on Morello. This work has been the recent subject of a report from the Microsoft Security Response Center (MSRC), Microsoft’s internal red team and security response organization, describing how CHERI has to potential to deterministically prevent over 2/3 of critical Microsoft software security vulnerabilities. CheriBSD/Morello brings that work over from our research CHERI-MIPS and CHERI-RISC-V platforms to Arm’s Morello. We demonstrated CheriBSD/Morello mitigating several memory-safety vulnerabilities in the EPSRC Digital Security by Design (DSbD) workshop yesterday, talking to 9 UK universities that have been funded to do research building on CHERI and Morello.

We have an aggressive planned quarterly release schedule through the end of 2021 when a full release will ship alongside the Morello board, adapting various CheriBSD security features to Morello:

DateReleaseKey features
October 2020Developer PreviewCheriABI pure-capability userspace implementing spatial memory safety.
December 2020Update 1Pure-capability kernel implementing spatial memory safety.
March 2021Update 2Userspace heap temporal memory safety based on Cornucopia (in collaboration with Microsoft Research).
June 2021Update 3Userspace software compartmentalization based on the CHERI co-process model.
October 2021Update 4Userspace software compartmentalization based on a run-time linker model.
Late 2021Full releaseAny updates required to operate well on the shipping Morello board.
CHERI software stack – working release schedule for 2020-2021

Getting started with CheriBSD/Morello is easy (if you have a tolerance for experimental architectural simulators, experimental operating systems, and experimental compilers!). Visit our CHERI Morello software web page to learn more about this work, and then our CheriBSD/Morello distribution page to download our build environment. You can automatically install Arm’s FVP, cross-develop in our docker-based SDK on macOS or Linux, and SSH into the simulated host to try things out.

CHERI is the work of a large research team at SRI International and the University of Cambridge, as well as numerous industrial collaborators at Arm, Google, Microsoft, and elsewhere. My co-investigators, Peter G. Neumann (SRI), Simon W. Moore (Cambridge), Peter Sewell (Cambridge), and I are immensely grateful for their contributions: CHERI would simply not have been possible without your collective effort – thank you! We are also grateful to our sponsors over an extended period, including DARPA, UKRI, Google, and Arm.

Security and Human Behaviour 2020

I’ll be liveblogging the workshop on security and human behaviour, which is online this year. My liveblogs will appear as followups to this post. This year my program co-chair is Alice Hutchings and we have invited a number of eminent criminologists to join us. Edited to add: here are the videos of the sessions.

How to jam neural networks

Deep neural networks (DNNs) have been a very active field of research for eight years now, and for the last five we’ve seen a steady stream of adversarial examples – inputs that will bamboozle a DNN so that it thinks a 30mph speed limit sign is a 60 instead, and even magic spectacles to make a DNN get the wearer’s gender wrong.

So far, these attacks have targeted the integrity or confidentiality of machine-learning systems. Can we do anything about availability?

Sponge Examples: Energy-Latency Attacks on Neural Networks shows how to find adversarial examples that cause a DNN to burn more energy, take more time, or both. They affect a wide range of DNN applications, from image recognition to natural language processing (NLP). Adversaries might use these examples for all sorts of mischief – from draining mobile phone batteries, though degrading the machine-vision systems on which self-driving cars rely, to jamming cognitive radar.

So far, our most spectacular results are against NLP systems. By feeding them confusing inputs we can slow them down over 100 times. There are already examples in the real world where people pause or stumble when asked hard questions but we now have a dependable method for generating such examples automatically and at scale. We can also neutralize the performance improvements of accelerators for computer vision tasks, and make them operate on their worst case performance.

One implication is that engineers designing real-time systems that use machine learning will have to pay more attention to worst-case behaviour; another is that when custom chips used to accelerate neural network computations use optimisations that increase the gap between worst-case and average-case outcomes, you’d better pay even more attention.

Three Paper Thursday: Vulnerabilities! We’ve got vulnerabilities here! … See? Nobody cares.

Jurassic Park is often (mistakenly) left out of the hacker movie canon. It clearly demonstrated the risk of an insider attack on control systems (Velociraptor rampage, amongst other tragedies…) nearly a decade ahead of the Maroochy sewage incident, it’s the first film I know of with a digital troll (“ah, ah, ah, you didn’t say the magic word!”), and Samuel L. Jackson correctly assesses the possible consequence of a hard reset (namely, everyone dying), resulting in his legendary “Hold on to your butts”. The quotable mayhem is seeded early in the film, when biotech spy Lewis Dodgson gives a sack of money to InGen’s Dennis Nedry to steal some dino DNA. Dodgson’s caricatured OPSEC (complete with trilby and dark glasses) is mocked by Nedry shouting, “Dodgson! Dodgson! We’ve got Dodgson here! See, nobody cares…” Three decades later, this quote still comes to mind* whenever conventional wisdom doesn’t seem to square with observed reality, and today we’re going to apply it to the oft-maligned world of Industrial Control System (ICS) security.

There is plenty of literature on ICS security pre-2010, but people really sat up and started paying attention when we learned about Stuxnet. Possibly the most upsetting thing about Stuxnet (for security-complacent control system designers like me) was the apparent ease with which the “air gap” was bridged over and over again. Any remaining faith in the air gap was killed by Éireann Leverett’s demonstration (thesis and S4 presentation) that thousands of industrial systems were directly connected to the Internet — no air gap jumping required. Since then, we’ve observed a steady growth in Internet-connected ICS devices, due both to improved search techniques and increasingly-connectable ICS devices. On any given day you can find about 100,000 unique devices speaking industrial protocols on Censys and Shodan. These protocols are largely unauthenticated and unencrypted, allowing an attacker that can speak the protocol to remotely read state, issue commands, and even modify programmable logic without using an actual exploit.

This sounds (and is) bad, and people have (correctly) highlighted its badness on many occasions. The attacks, however, appear to be missing: we are not aware of a single instance of industrial damage initiated via an Internet-connected ICS device. In this Three Paper Thursday we’ll look at papers showing how easy it is to find and contextualise Internet-connected ICS devices, some evidence for lack of malicious interest, and some leading indicators that this happy conclusion (for which we don’t really deserve any credit) may be changing.

*Perhaps because guys of a certain age still laugh and say “Dodson! We’ve got Dodson here!” when they learn my surname. I try to explain that it’s spelt differently, but…
Continue reading Three Paper Thursday: Vulnerabilities! We’ve got vulnerabilities here! … See? Nobody cares.

Contact Tracing in the Real World

There have recently been several proposals for pseudonymous contact tracing, including from Apple and Google. To both cryptographers and privacy advocates, this might seem the obvious way to protect public health and privacy at the same time. Meanwhile other cryptographers have been pointing out some of the flaws.

There are also real systems being built by governments. Singapore has already deployed and open-sourced one that uses contact tracing based on bluetooth beacons. Most of the academic and tech industry proposals follow this strategy, as the “obvious” way to tell who’s been within a few metres of you and for how long. The UK’s National Health Service is working on one too, and I’m one of a group of people being consulted on the privacy and security.

But contact tracing in the real world is not quite as many of the academic and industry proposals assume.

First, it isn’t anonymous. Covid-19 is a notifiable disease so a doctor who diagnoses you must inform the public health authorities, and if they have the bandwidth they call you and ask who you’ve been in contact with. They then call your contacts in turn. It’s not about consent or anonymity, so much as being persuasive and having a good bedside manner.

I’m relaxed about doing all this under emergency public-health powers, since this will make it harder for intrusive systems to persist after the pandemic than if they have some privacy theater that can be used to argue that the whizzy new medi-panopticon is legal enough to be kept running.

Second, contact tracers have access to all sorts of other data such as public transport ticketing and credit-card records. This is how a contact tracer in Singapore is able to phone you and tell you that the taxi driver who took you yesterday from Orchard Road to Raffles has reported sick, so please put on a mask right now and go straight home. This must be controlled; Taiwan lets public-health staff access such material in emergencies only.

Third, you can’t wait for diagnoses. In the UK, you only get a test if you’re a VIP or if you get admitted to hospital. Even so the results take 1–3 days to come back. While the VIPs share their status on twitter or facebook, the other diagnosed patients are often too sick to operate their phones.

Fourth, the public health authorities need geographical data for purposes other than contact tracing – such as to tell the army where to build more field hospitals, and to plan shipments of scarce personal protective equipment. There are already apps that do symptom tracking but more would be better. So the UK app will ask for the first three characters of your postcode, which is about enough to locate which hospital you’d end up in.

Fifth, although the cryptographers – and now Google and Apple – are discussing more anonymous variants of the Singapore app, that’s not the problem. Anyone who’s worked on abuse will instantly realise that a voluntary app operated by anonymous actors is wide open to trolling. The performance art people will tie a phone to a dog and let it run around the park; the Russians will use the app to run service-denial attacks and spread panic; and little Johnny will self-report symptoms to get the whole school sent home.

Sixth, there’s the human aspect. On Friday, when I was coming back from walking the dogs, I stopped to chat for ten minutes to a neighbour. She stood halfway between her gate and her front door, so we were about 3 metres apart, and the wind was blowing from the side. The risk that either of us would infect the other was negligible. If we’d been carrying bluetooth apps, we’d have been flagged as mutual contacts. It would be quite intolerable for the government to prohibit such social interactions, or to deploy technology that would punish them via false alarms. And how will things work with an orderly supermarket queue, where law-abiding people stand patiently six feet apart?

Bluetooth also goes through plasterboard. If undergraduates return to Cambridge in October, I assume there will still be small-group teaching, but with protocols for distancing, self-isolation and quarantine. A supervisor might sit in a teaching room with two or three students, all more than 2m apart and maybe wearing masks, and the window open. The bluetooth app will flag up not just the others in the room but people in the next room too.

How is this to be dealt with? I expect the app developers will have to fit a user interface saying “You’re within range of device 38a5f01e20. Within infection range (y/n)?” But what happens when people get an avalanche of false alarms? They learn to click them away. A better design might be to invite people to add a nickname and a photo so that contacts could see who they are. “You are near to Ross [photo] and have been for five minutes. Are you maintaining physical distance?”

When I discussed this with a family member, the immediate reaction was that she’d refuse to run an anonymous app that might suddenly say “someone you’ve been near in the past four days has reported symptoms, so you must now self-isolate for 14 days.” A call from a public health officer is one thing, but not knowing who it was would just creep her out. It’s important to get the reactions of real people, not just geeks and wonks! And the experience of South Korea and Taiwan suggests that transparency is the key to public acceptance.

Seventh, on the systems front, decentralised systems are all very nice in theory but are a complete pain in practice as they’re too hard to update. We’re still using Internet infrastructure from 30 years ago (BGP, DNS, SMTP…) because it’s just too hard to change. Watch Moxie Marlinspike’s talk at 36C3 if you don’t get this. Relying on cryptography tends to make things even more complex, fragile and hard to change. In the pandemic, the public health folks may have to tweak all sorts of parameters weekly or even daily. You can’t do that with apps on 169 different types of phone and with peer-to-peer communications.

Personally I feel conflicted. I recognise the overwhelming force of the public-health arguments for a centralised system, but I also have 25 years’ experience of the NHS being incompetent at developing systems and repeatedly breaking their privacy promises when they do manage to collect some data of value to somebody else. The Google Deepmind scandal was just the latest of many and by no means the worst. This is why I’m really uneasy about collecting lots of lightly-anonymised data in a system that becomes integrated into a whole-of-government response to the pandemic. We might never get rid of it.

But the real killer is likely to be the interaction between privacy and economics. If the app’s voluntary, nobody has an incentive to use it, except tinkerers and people who religiously comply with whatever the government asks. If uptake remains at 10-15%, as in Singapore, it won’t be much use and we’ll need to hire more contact tracers instead. Apps that involve compulsion, such as those for quarantine geofencing, will face a more adversarial threat model; and the same will be true in spades for any electronic immunity certificate. There the incentive to cheat will be extreme, and we might be better off with paper serology test certificates, like the yellow fever vaccination certificates you needed for the tropics, back in the good old days when you could actually go there.

All that said, I suspect the tracing apps are really just do-something-itis. Most countries now seem past the point where contact tracing is a high priority; even Singapore has had to go into lockdown. If it becomes a priority during the second wave, we will need a lot more contact tracers: last week, 999 calls in Cambridge had a 40-minute wait and it took ambulances six hours to arrive. We cannot field an app that will cause more worried well people to phone 999.

The real trade-off between surveillance and public health is this. For years, a pandemic has been at the top of Britain’s risk register, yet far less was spent preparing for one than on anti-terrorist measures, many of which were ostentatious rather than effective. Worse, the rhetoric of terror puffed up the security agencies at the expense of public health, predisposing the US and UK governments to disregard the lesson of SARS in 2003 and MERS in 2015 — unlike the governments of China, Singapore, Taiwan and South Korea, who paid at least some attention. What we need is a radical redistribution of resources from the surveillance-industrial complex to public health.

Our effort should go into expanding testing, making ventilators, retraining everyone with a clinical background from vet nurses to physiotherapists to use them, and building field hospitals. We must call out bullshit when we see it, and must not give policymakers the false hope that techno-magic might let them avoid the hard decisions. Otherwise we can serve best by keeping out of the way. The response should not be driven by cryptographers but by epidemiologists, and we should learn what we can from the countries that have managed best so far, such as South Korea and Taiwan.

Honware: A Virtual Honeypot Framework for Capturing CPE and IoT Zero Days

Existing defenses are slow to detect zero day exploits and capture attack traffic targeting inadequately secured Customer Premise Equipment (CPE) and Internet of Things (IoT) devices. This means that attackers have considerable periods of time to find and compromise vulnerable devices before the attack vectors are well understood and mitigation is in place.

About a month ago we presented honware at eCrime 2019, a new honeypot framework that enables the rapid construction of honeypots for a wide range of CPE and IoT devices. The framework automatically processes a standard firmware image (as is commonly provided for updates) and runs the system with a special pre-built Linux kernel without needing custom hardware. It then logs attacker traffic and records which of their actions led to a compromise.

We provide an extensive evaluation and show that our framework is scalable and significantly better than existing emulation strategies in emulating the devices’ firmware applications. We were able to successfully process close to 2000 firmware images across a dozen brands (TP-Link, Netgear, D-Link…) and run them as honeypots. Also, as we use the original firmware images, the honeypots are not susceptible to fingerprinting attacks based on protocol deviations or self-revealing properties.

By simplifying the process of deploying realistic honeypots at Internet scale, honware supports the detection of malware types that often go unnoticed by users and manufactures. We hope that honware will be used at Internet scale by manufacturers setting up honeypots for all of their products and firmware versions or by researchers looking for new types of malware.

The paper is available here.

Security Engineering, and Sustainability

Yesterday I got the audience at the 36th Chaos Computer Congress in Leipzig to vote on the cover art for the third edition of my textbook on Security Engineering: you can see the result here.

It was a privilege to give a talk at 36C3; as the theme was sustainability, I spoke on The Sustainability of Safety, Security and Privacy. This is a topic on which I’ve written and spoken several times in recent years, but we now have some progress to report. The EU has changed the rules to require that if you sell goods with digital components (whether embedded software, associated cloud services or smartphone apps) then these have to be maintained for as long as the customer might reasonably expect.

UKRI Digital Security by Design: A £190M research programme around Arm’s Morello – an experimental ARMv8-A CPU, SoC, and board with CHERI support

PIs: Robert N. M. Watson (Cambridge), Simon W. Moore (Cambridge), Peter Sewell (Cambridge), and Peter G. Neumann (SRI)

Since 2010, SRI International and the University of Cambridge, supported by DARPA, have been developing CHERI: a capability-system extension to RISC Instruction-Set Architectures (ISAs) supporting fine-grained memory protection and scalable compartmentalization .. while retaining incremental deployability within current C and C++ software stacks. This ten-year research project has involved hardware-software-semantic co-design: FPGA prototyping, compiler development, operating-system development, and application adaptation, as well as formal modeling and proof. Extensively documented in technical reports and research papers, we have iterated on CHERI as we evaluated and improved microarchitectural overheads, performance, software compatibility, and security.

As we know, mainstream computer systems are still chronically insecure. One of the main reasons for this is that conventional hardware architectures and C/C++ language abstractions, dating back to the 1970s, provide only coarse-grained memory protection. Without memory safety, many coding errors turn into exploitable security vulnerabilities. In our ASPLOS 2019 paper on CheriABI (best paper award), we demonstrated that a complete UNIX userspace and application suite could be protected by strong memory safety with minimal source-code disruption and acceptable performance overheads. Scalable software compartmentalization offers mitigation for future unknown classes of vulnerabilities by enabling greater use of design patterns such as software sandboxing. Our An Introduction to CHERI technical report introduces our approach including the architecture, microarchitectural contributions, formal models, software protection model, and practical software adaptation. The CHERI ISA v7 specification is the authoritative reference to the architecture, including both the architecture-neutral protection model and its concrete mappings into the 64-bit MIPS and 32/64-bit RISC-V ISAs. Our Rigorous Engineering technical report describes our modelling and mechanised proof of key security properties.

Today, we are very excited to be able to talk about another long-running aspect of our DARPA-supported work: A collaboration since 2014 with engineers at Arm to create an experimental adaptation of CHERI to the ARMv8-A architecture. This widely used ISA is the foundation for the vast majority of mobile phones and tablets, including those running iOS and Android. The £170M UKRI program Digital Security by Design (DSbD) was announced in late September 2019 to explore potential applications of CHERI — with a £70M investment by UKRI, and a further £117M from industry including involvement by Arm, Microsoft, and Google. Today, UKRI and Arm announced that the Arm Morello board will become available from 2021: Morello is a prototype 7nm high-end multi-core superscalar ARMv8-A processor (based on Arm’s Neoverse N1), SoC, and board implementing experimental CHERI extensions. As part of this effort, the UK Engineering and Physical Sciences Research Council (EPSRC) has also announced a new £8M programme to fund UK academics to work with Morello. Arm will release their Morello adaptation of our CHERI Clang/LLVM toolchain, and we will release a full adaptation of our open-source CHERI reference software stack to Morello (including our CheriBSD operating system and application suite) as foundations for research and prototyping on Morello. Watch the DSbD workshop videos from Robert Watson (Cambridge), Richard Grisenthwaite (Arm), and Manuel Costa (Microsoft) on CHERI and Morello, which are linked below, for more information.

This is an incredible opportunity to validate the CHERI approach, with accompanying systems software and formal verification, through an industrial scale and industrial quality hardware design, and to broaden the research community around CHERI to explore its potential impact. You can read the announcements about Morello here:

Recordings of several talks on CHERI and Morello are now available from the ISCF Digital Security by Design Challenge Collaborators’ Workshop (26 September 2019), including:

  • Robert Watson (Cambridge)’s talk on CHERI, and on our transition collaboration with Arm (video) (slides)
  • Richard Grisenthwaite (Arm)’s talk on the Morello board and CHERI transition (video) (slides)
  • Manuel Costa (Microsoft)’s talk on memory safety and potential opportunities arising with CHERI and Morello (video)

In addition, we are maintaining a CHERI DSbD web page with background information on CHERI, announcements regarding Morello, links to DSbD funding calls, and information regarding software artefacts, formal models, and so on. We will continue to update that page as the programme proceeds.

This has been possible through the contributions of the many members of the CHERI research team over the last ten years, including: Hesham Almatary, Jonathan Anderson, John Baldwin, Hadrien Barrel, Thomas Bauereiss, Ruslan Bukin, David Chisnall, James Clarke, Nirav Dave, Brooks Davis, Lawrence Esswood, Nathaniel W. Filardo, Khilan Gudka, Brett Gutstein, Alexandre Joannou, Robert Kovacsics, Ben Laurie, A. Theo Markettos, J. Edward Maste, Marno van der Maas, Alfredo Mazzinghi, Alan Mujumdar, Prashanth Mundkur, Steven J. Murdoch, Edward Napierala, Kyndylan Nienhuis, Robert Norton-Wright, Philip Paeps, Lucian Paul-Trifu, Alex Richardson, Michael Roe, Colin Rothwell, Peter Rugg, Hassen Saidi, Stacey Son, Domagoj Stolfa, Andrew Turner, Munraj Vadera, Jonathan Woodruff, Hongyan Xia, and Bjoern A. Zeeb.

Approved for public release; distribution is unlimited. This work was supported by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contract FA8750-10-C-0237 (CTSRD), with additional support from FA8750-11-C-0249 (MRC2), HR0011-18-C-0016 (ECATS), and FA8650-18-C-7809 (CIFV) as part of the DARPA CRASH, MRC, and SSITH research programs. The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. We also acknowledge the EPSRC REMS Programme Grant (EP/K008528/1), the ERC ELVER Advanced Grant (789108), the Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF), Thales E-Security, Microsoft Research Cambridge, Arm Limited, Google, Google DeepMind, HP Enterprise, and the Gates Cambridge Trust.