Security Concerns

[john]

Hey,
After reading your information about the quite simple imaging process of your Revolution Pi and your blog page about security precautions, I'm having still some concerns:

• Is it possible to encrypt the entire hard drive? Since everybody with a micro USB cable with physical access to the device is able to get an image dump, all stored secrets (e.g. certificates, stored keys, IP) can been read out.
• Since you emphasised in another forum post, the ATECC508A will not be accessible, do you provide any extension or module based HSM or TPM?

Best regards
John

[Mathias]

Hi John,

• Is it possible to encrypt the entire hard drive? Since everybody with a micro USB cable with physical access to the device is able to get an image dump, all stored secrets (e.g. certificates, stored keys, IP) can been read out.

That's a principle problem of all computers. If someone has physical access to the computer, he can access the stored data. Of course, you can encrypt the data in an encrypted file system, but the key must also be stored somewhere on the device and can be accessed by somebody who has physical access to the computer.

• Since you emphasised in another forum post, the ATECC508A will not be accessible, do you provide any extension or module based HSM or TPM?

The ATECC508A has similar features as a TPM. Unfortunatelly we do not have examples yet, how this chip can be used. You can get the documentation of this chip from Atmel, if you sign a NDA.

Mathias

[john]

Hey Mathias,

That's a principle problem of all computers. If someone has physical access to the computer, he can access the stored data. Of course, you can encrypt the data in an encrypted file system, but the key must also be stored somewhere on the device and can be accessed by somebody who has physical access to the computer.

I have to disagree with your statement. There is no doubt, that an attacker with unlimited physical access to the device is able to access the data (at least as long you don't use full disk encryption e.g. Bitlocker, or LUKS), since you can't prevent a motivated attacker from disassemble the device and reading the flash pages with an external reader. But since this attack cost substantially more time, the attacker wouldn't be able to dump the stored data within some minutes, as I stated before. Of course full disc encryption would be out of scope for the limited device resources, but disabling the imaging interface on the outside (or enabling SecureBoot against Image manipulation) would at least increase security against people walking by.

The ATECC508A has similar features as a TPM. Unfortunatelly we do not have examples yet, how this chip can be used. You can get the documentation of this chip from Atmel, if you sign a NDA.

Signing an NDA would't be a problem at all, but working and developing is absurd, even with full documentation, if you cant assure a life cycle for the chip. As your coworker Volker wrote in viewtopic.php?t=825:

The crypto chip may not as it is not part of our open source concept and restricted for KUNBUS and/or OEM use (i.e. KUNBUS may replace the chip in future releases without public notification and without backward compatibility...

Why should we strive to sign the NDA, as our development work could be useless for any future release?

Let me put my previous questions in another way: Do you provide any security modules or components besides Let' Encrypt certificates to hardening the Revolution Pi?

John

Edit: Feel free to move this post to the hardware topic, if you think it's more suitable.

[Mathias]

Hi John,
the Micro USB Port is the only way to program the eMMC the first time. It's also the only way to access the eMMC without opening the case if the operating system crashes or the user loses his password. I know it sounds a little silly, you could put some glue in the plug to make it unusable.
To your question: no, we don't offer any other security mechanisms at the moment.
Best regards
Mathias

[john]

Hey Mathias,

thanks for your honest response. We will analyse, how our security requirements can be full filled with your device and what other actions have to been taken.

Best regards
John

[Wulf]

I don't think that secure boot is possible on the RevPi.

The ATECC508A chip's documentation is available without NDA: https://www.microchip.com/mymicrochip/f ... e=en590686
I asked Microchip if the data sheet is accessible by intention; it is. They decided to make it public now that they also sell the ATECC608A.
Note that Kunbus wants you to sign a special contract before you may use the chip.

You could use the chip to store (or decrypt) the hard drive encryption key, or the private key that you use for e.g. TLS connections.
Then the attacker not only needs to create a copy of the eMMC, they also need access to the chip. E.g. by booting a different system through USB.
It makes the attack a bit more complicated, but doesn't prevent it.

The https://www.microchip.com/wwwproducts/en/ATECC608A offers "Secure boot support". But I doubt that it's really secure. I still need to get my hands on the full datasheet (under NDA).

For secure boot, the CPU needs to support it, and the CPU on the Raspberry Pi doesn't. (Someone correct me if I'm wrong!)
And even if a CPU supports it, there are other ways to break in, e.g. exploit a flaw in the CPU or in software that's running on the device.

If you want to harden your RevPi (against whom?), take physical measures. Lock it into a cabinet, place a fluffy guard dog in front of it.
If your overall security concept depends on the security of a device where random people have physical access to, your concept needs rethinking.

Assume that someone will steal the keys from your device, no matter what hardware you use and no matter what else you try to prevent it.

[stephan]

Have you taken any measures to make the RevPi more secure?

According to the Specs for your current crypto-chip ATECC508A it supports Secure Boot, as well as Anti-Cloning. Can this be used through the RevPi?

We want to make sure that only signed software can be run. We're also interested in how Anti-Cloning is realized with the crypto-chip.

[jenskastensson]

one more client interested in anti cloning !

[lukas]

SecureBoot is supported by the ATECC608A only insofar as the CPU supports it. The CPU can then ask the ATECC608A to perform digest validation. However as Wulf has correctly pointed out, the Raspberry Pi's BCM2835 CPU doesn't support SecureBoot.

As to full disk encryption, a quick Google search turns up a Raspberry Pi LUKS Root Encryption tutorial. This will allow you to encrypt the eMMC and thus protect any secrets stored thereon if the RevPi is stolen. The passphrase to unlock the LUKS container needs to be entered manually every time the RevPi is booted.

It should be possible to use the ATECC508A on the RevPi base board for LUKS authentication. The problem is that the manufacturer (Atmel, now Microchip) provides an OpenSSL module (called CryptAuthLib) which only works with an outdated OpenSSL version. Shipping a working OpenSSL module to access the ATECC508A is on our agenda but we cannot provide an ETA at this point.

If LUKS authentication is done via the ATECC508A, you can protect against readout of the eMMC via the USB port on the front, but not against attackers stealing the RevPi and reading out the eMMC contents at runtime.

Note that even if you destroy the USB port on the front (by filling it with glue or forcefully removing the USB connector from the base board), an attacker may still open the case, remove the Compute Module and insert it in a separate RevPi base board which has a functioning USB connector on the front.

I'm not sure what you mean by "anti-cloning" (Google only comes up with genetic cloning material using that search term). I hope I've answered your questions to satisfaction. Let us know if there are any further questions.

[jenskastensson]

I think the anti-cloning term refers to the process of reading the image file from one device, and then writing it on another device.