TPM module for Raspberry Pi?

[bson]

I'm looking to do some quick and dirty proof of concept for a project, and need a TPM module that will work with a Raspberry pi with minimal fuss.  I2C, SPI, or parallel doesn't matter - in fact performance is mostly irrelevant; the POC only needs to the TPM for the PKCS private RSA key, using it to identify itself (indirectly, by proof of knowledge and by generating session secrets and HMAC signing keys).  The public key will of course be totally public.  The private key won't be used for anything else at all (though obviously it needs to implement the RSA bignum expmod so this will be implicitly offloaded).  I don't need secure boot or anything like that; this is intended to be customer premises equipment and if they want to fiddle with it they're perfectly welcome to and the only requirement is they can't change or directly access the private key.  (This is for trust to prevent impersonation, MITM, key leaks, etc.) I *could* do PKCS in software using only openssh, but the hardware private key part is a major selling point...

Some GPIO and a couple of relays would be handy as well.

I'd rather not spend time rolling my own here just for a super simple POC demonstration...

[bson]

Maybe the easiest is just grab an Atmel TPM chip in TSSOP and add a PCF8574 and a few relay FET drivers, and toss it all on a board...  It seems Linux already has stock drivers for TPC-compliant TPM.  E.g. http://www.microchip.com/wwwproducts/en/AT97SC3205T.

[stj]

try ebay, some p4 laptops had the TPM on a sub-board that just plugged in, so it could be left out for some export markets.

like this:
http://www.ebay.co.uk/itm/Foxconn-PC-TMP-KRYPTON-Trusted-platform-Module-rev-1-0-TPM-KRYPTON-/161687737377

[bson]

Nice!  But I decided I can just take one of those 28-pin TSSOPs and stick it on a small adapter board...  It just needs four pins anyway; 3.3V, GND, SCL, and SDA.  So I ordered half dozen chips (just over $3 each from Mouser), should be quick and easy and this way I know what I'm working with.

[technix]

What do you want to achieve with the TPM?

Maybe you can make use of the ATAES132A and ATECC508A if you know how to use them.

[peter.huewe]

Actually Infineon Technologies (my employer) does even have a TPM daughterboard for the RPI2/3 and an application note how to set some stuff up.
See:
https://www.infineon.com/cms/de/product/security-and-smart-card-solutions/optiga-embedded-security-solutions/optiga-tpm/channel.html?channel=5546d462503812bb015066de24291768#ispnTab3
Infineon SLB 9645 / SLB 9670 TPM 1.2 with Embedded Platform Integration on a Raspberry Pi® 2
Infineon SLB 9670 TPM 2.0 on a Raspberry Pi 3 EN

Infineon's sub-company Hitex now has the eval boards for RPI in stock:
https://www.ehitex.de/en/evaluation-boards/infineon/2564/iridium-9670-tpm2.0-spi TPM2.0 SPI
https://www.ehitex.de/en/evaluation-boards/infineon/2563/iridium-9670-tpm1.2-spi TPM1.2 SPI
https://www.ehitex.de/en/evaluation-boards/infineon/2562/iridium-9645-tpm1.2-i2c TPM1.2 I2C

or as a lower cost alternative the german Raspberry Pi distributor buyzero/pi3g has it's own Infineon SLB9670 TPM SPI board in stock:
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module

Even the drivers are upstream and included in the rpi kernel sources (Just have to enable them and add a suitable device tree entry)

Here you can also find a blog post on how to get the TPM support going
http://letstrust.de/archives/9-Howto-Enable-TPM-Support-on-a-Raspberry-PI-0,-0W,-1,-2,-3-and-make-it-work-with-the-LetsTrust-TPM.html

Thanks,
Peter

Disclaimer: I work for Infineon (and wrote the driver (and am the TPM subsystem maintainer))

[Kjelt]

Now you have to solve the security chicken and egg problem:
- you have a strong encrypted vault with some secret key inside  .
The big question, how can you use this secret or how do you get it out on a HW platform where the entire firmware is on an unprotected external flash disk, ergo any hacker can reproduce your code ?

[helius]

(This is for trust to prevent impersonation, MITM, key leaks, etc.)

These aren't such ambitious requirements that you should have a problem. The issues raised by Kjelt are valid, but in this situation you can make sure that the identity is real by following standard security practices. One point is that a hardware MITM attack is possible by attaching between the TPM and the Pi: make sure that you design your protocol to protect from this, using timestamps, certificate chains etc.

[mikeselectricstuff]

https://rutronik-tec.com/optiga-tpm-slb-9645-with-raspberry-pi-2/

[Kjelt]

Well if indeed the only thing you want to do is authenticate the hardware to an external own server or third party that will not be such a big problem if the TPM can execute the algorithm autonomously which most can.
My first read and understanding was that security senstive information needed to be confidentially transferred between parties, in which case physical access to this device is enough to break it.

[technix]

Now you have to solve the security chicken and egg problem:
- you have a strong encrypted vault with some secret key inside  .
The big question, how can you use this secret or how do you get it out on a HW platform where the entire firmware is on an unprotected external flash disk, ergo any hacker can reproduce your code ?

Make sure the private keys never leave the TPM (as it should be designed to be) and preferably generated within it. This way there would be no way for even the application to ever see the private keys once it is installed. Then you can use TLS with Client Certificate Authentication and a strong cipher suite (like ECDHE-ECDSA-CHACHA20-POLY1305-SHA256/ECDHE-ECDSA-AES128-GCM-SHA256 if the TPM supports ECDSA certificates, or ECDHE-RSA-CHACHA20-POLY1305-SHA256/ECDHE-RSA-AES128-GCM-SHA256 if the TPM only supports RSA.) TLS with Client Certificate Authentication and strong cipher can allow you to establish confidentiality, integrity and authenticity between two TPM-equipped nodes without having the private keys ever leave the TPM itself.

Ephemeral-key Diffie-Hellman Key Exchange gives the connection resistance against compromised certificates (as keys are not encrypted with certificates) or session keys (as each key is only used for a very short time before renegotiated over Diffie-Hellman, forcing the session key crack to restart de novo) allowing for perfect forward secrecy. The two cipher suites I have suggested, AES with 128-bit keys in Galois-Counter Mode, and ChaCha20-Poly1305, are strong as of posting, and provide message encryption and message authentication using the same algorithm. AES may require additional hardware to perform well on embedded platforms (like the embedded crypto engine found in STM32F439.) ChaCha20-Poly1305 is optimized for 32-bit embedded processors without additional hardware accelerators.

[Kjelt]

Yes but if the TPM generates the private key you need to store the public key in the factory or you do not know if it is your own device (authentication).
Alternatively, in the factory you can program the pub/priv keypairs in the tpm's from the database you generate on forehand.
This could all work, rather costly though regarding the price of TPM's often are higher than a cortex Mx processor.

BTW Technix I heard that in China you need (only allowed) to use China govt. approved ciphers, probably weakend so they can listen in?

[technix]

Yes but if the TPM generates the private key you need to store the public key in the factory or you do not know if it is your own device (authentication).
Alternatively, in the factory you can program the pub/priv keypairs in the tpm's from the database you generate on forehand.
This could all work, rather costly though regarding the price of TPM's often are higher than a cortex Mx processor.

BTW Technix I heard that in China you need (only allowed) to use China govt. approved ciphers, probably weakend so they can listen in?

Here is a third alternative: During manufacturing the device's built-in (readable) unique identifier is recorded but no private key is installed (only your public key is installed) so there is no serialization performed on your side. Now you have a database of unactivated devices in the form of TPM unique identifiers with no certificate associated. You also operate a certificate authority that is trusted by the TPM and the host system.

Upon the first time a user boots the device up, a fresh certificate signing request and associated private key is generated within the device, with the unique ID embedded in the request. This certificate signing request is sent to the server (TLS without client certificate authentication used here, but as long as this new device registration is the only API accessible without a client certificate it should not affect the overall security.) The server, upon seeing this certificate signing request, checks whether the embedded unique ID have a previous certificate associated with it. If no, the certificate signing request is honored and signed into a full certificate that is installed to the device's TPM (and further communication can be carried out using this client certificate.) If a previous certificate is detected some investigatory steps can be taken to detect potential equipment theft.

[technix]

Yes but if the TPM generates the private key you need to store the public key in the factory or you do not know if it is your own device (authentication).
Alternatively, in the factory you can program the pub/priv keypairs in the tpm's from the database you generate on forehand.
This could all work, rather costly though regarding the price of TPM's often are higher than a cortex Mx processor.

BTW Technix I heard that in China you need (only allowed) to use China govt. approved ciphers, probably weakend so they can listen in?

The government have published the algorithms as recommendations for now, but since none of the IPSec, TLS or PCI standards accept those ciphers the gov't is not enforcing it.