At the core of ORWL’s physical security are two secure microcontroller units (MCUs), one on the mainboard (Maxim’s MAX32550) and one in the key fob (STMicroelectronics’ ST54D). This update goes into detail about the secure MCUs.

Roles of the Secure Microcontrollers

The secure MCUs are the foundation of all ORWL’s physical security measures:

• Encrypted Data: All data is automatically encrypted on a self-encrypting SSD. The key ultimately needed to decrypt the SSD is stored on the mainboard secure MCU and given to the SSD only after the user is authenticated with the key fob.
• Tamper-proof Active Mesh: The entire ORWL device, including the mainboard secure MCU, CPU, and SSD, is covered in a tamper-proof mesh actively monitored by the mainboard secure MCU and its backup battery.
• Self-destruct: When a tamper in the mesh is detected, the mainboard secure MCU immediately destroys the decryption key, thereby making all data on the SSD inaccessible.
• Key Fob Authentication: The mainboard secure MCU authenticates the key fob using a dedicated NFC reader and monitors the distance of the key fob using a dedicated BLE module. ORWL’s Intel subsystem, which doesn’t have access to the NFC or BLE modules, is powered only after authenticating the key fob (NFC) and verifying its proximity (BLE). A standard login process with username and password is still required.
• AFK Lockdown: When the key fob is out of a pre-defined range, the mainboard secure MCU, with the help of the custom BIOS, puts the system into standby mode and disables all USB ports.

Motion Alarm: While the key fob is out of range, the mainboard secure MCU monitors a dedicated inertial measurement unit (three-axis accelerometer + three-axis gyroscope). Any motion above a pre-defined threshold will cause the mainboard secure MCU to cut power to the Intel subsystem.

• Off-grid Backup: The mainboard secure MCU’s backup battery will last several months. When the battery runs low, the mainboard secure MCU destroys the encryption key in the same way as if a tamper event had occurred.

Clearly, if either of the secure MCUs is compromised, the entire system is compromised. As such, it’s worth digging deeper into what exactly makes them secure and trustworthy in the first place.

Features of the Secure Microcontrollers

Secure MCUs have been around for a while, but their use has so far been limited to primarily industries dealing with confidential or sensitive data, such as finance, military, and medical. As far as we know, ORWL is the first personal computer to incorporate a secure MCU.

A typical secure MCU will have the same basic functionality as a regular MCU, but with some extra features specifically geared toward protecting data from unauthorized access and corruption.

Die Shield

A common feature of secure MCUs is a conductive mesh, called a die shield, built into the actual packaging of the integrated circuit, completely surrounding it. Die shields can detect physical intrusion and thereby trigger the secure MCU to destroy sensitive data before an adversary gains access. They also serve as electromagnetic shielding to prevent certain kinds of side-channel attacks.

Mainboard Secure MCU

The mainboard secure MCU is an ARM Cortex M3 with the following security features, to name a few:

• Die shield with self-erasing memory on tamper
• Hardware accelerators for cryptographic primitives
• Side channel protection for crypto operations
• True random number generator
• Six tamper sensors for monitoring the active mesh
• Temperature and voltage tamper monitors

Key Fob Secure MCU

The key fob secure MCU is an ARM Secure Core that implements the secure element aspect of near-field communication (NFC) and also has a die shield.

Trustworthiness of the Secure Microcontrollers

The datasheets linked to above for the Maxim and ST secure MCUs used in ORWL and its key fob are not full datasheets. Unfortunately, the only way to access the full datasheets for either of these parts, and indeed every other secure MCU we know of, is to enter into a non-disclosure agreement (NDA) with the manufacturer. Clearly, this is less than ideal - we all know security through obscurity does not work. Why, then, should we trust they are secure at all? There are two basic answers to this question: third-party verification and widespread adoption.

Third-party Verification

Having datasheets available under NDA is better than not having datasheets at all. We have entered into these NDAs and, in theory, anyone else who really wants to verify everything for themselves could enter into them as well. Of course, this is onerous, which is one reason we’ve engaged Penumbra, a third-party security company, to independently verify the security of ORWL. This work is ongoing and we will make the results public.

Widespread Adoption

Secure MCUs and the security standards they implement (e.g., ISO/IEC 7816-3) are used in millions of devices to safeguard sensitive information. For example, every payment card industry (PCI) point of sale system uses such secure MCUs. The total value of financial transactions alone going through secure MCUs every year is likely in the trillions of dollars. On one hand, there is a lot of incentive to find vulnerabilities in secure MCUs. On the other hand, there is a corresponding incentive to be sure there are no vulnerabilities. In other words, if ORWL is compromised because of a flaw or backdoor in its secure MCUs, then so too is a vast financial network. While far from a guarantee of security, the empirical evidence suggests at least a minimal level. Of course, just because all your friends are doing something stupid, doesn’t mean you should do it too. That said, there is a certain reassurance to be had in a common destiny.

Why NDAs?

If security through obscurity doesn’t work, why are NDAs required by the manufacturers of secure MCUs? To be honest, we’re not entirely sure, but we think it’s because of some combination of protecting intellectual property and catering to legacy ideas of security within the military and finance industries. For example, our contact at Maxim cited PCI compliance as one reason for the NDA. Secure MCUs fall under PCI PIN Transaction Security (PTS), which is used to certify retail payment terminals, in contrast to PCI Data Security Standard (DSS), which is often derided as having little security value. Though we can’t find the exact section of the labyrinthine PCI standard requiring an NDA, it is a standard expectation within the industry.

Developing for the Secure Microcontrollers

While the secure MCUs we ship as part of ORWL will be fully functional out of the box, some people are interested in verifying and reprogramming them on their own. For example, you may want to sign all firmware with your own key instead of the unique key we generate for each ORWL. Whatever the reason, we will try to make this as easy as possible.

Dev Kit

As a first step to giving users control over the firmware on their machines, we will soon announce a special "dev kit" pledge level that contains tools to build and verify all firmware from start to finish. You will still need to enter into NDAs with the manufacturers of the secure MCUs, but the dev kit should greatly streamline the process of putting together the right toolchain. Stay tuned.

Custom Secure Microcontroller

By far the most opaque part of the mainboard secure MCU is its boot ROM firmware. This is burned into the chip by Maxim, the manufacturer. However, Maxim has agreed to make a custom version of the secure MCU with no firmware on it. The cost of this customization is $20,000, which we are willing to pay. The bigger problem is finding someone willing and able to write open replacement firmware. If we go this route, we would need considerable help from the community. Of course, once complete, the custom secure MCUs would be available for anyone to use. Please contact us with any pointers or suggestions!