TPM module for Raspberry Pi? - Page 1
Forum section: electronics / general

author: bson
author_rank: Unknown
timestamp: May 15, 2017, 10:26:01 pm
content: 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...

author: bson
author_rank: Unknown
timestamp: May 15, 2017, 10:49:18 pm
content: 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.

author: stj
author_rank: Super Contributor
timestamp: May 15, 2017, 11:04:46 pm
content: 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

author: bson
author_rank: Unknown
timestamp: May 17, 2017, 03:26:59 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: May 19, 2017, 03:48:43 am
content: 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.

author: peter.huewe
author_rank: Newbie
timestamp: June 27, 2017, 11:43:04 am
content: 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#ispnTab3Infineon SLB 9645 / SLB 9670 TPM 1.2 with Embedded Platform Integration on a Raspberry Pi® 2Infineon SLB 9670 TPM 2.0 on a Raspberry Pi 3 ENInfineon'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-spiTPM2.0 SPIhttps://www.ehitex.de/en/evaluation-boards/infineon/2563/iridium-9670-tpm1.2-spiTPM1.2 SPIhttps://www.ehitex.de/en/evaluation-boards/infineon/2562/iridium-9645-tpm1.2-i2cTPM1.2 I2Cor 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-moduleEven 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 goinghttp://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.htmlThanks,PeterDisclaimer: I work for Infineon (and wrote the driver (and am the TPM subsystem maintainer))

author: Kjelt
author_rank: Super Contributor
timestamp: June 27, 2017, 12:06:28 pm
content: 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 ?

author: helius
author_rank: Super Contributor
timestamp: June 27, 2017, 01:20:46 pm
content: Quote from: bson on May 15, 2017, 10:26:01 pmThese 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 27, 2017, 01:31:16 pm
content: https://rutronik-tec.com/optiga-tpm-slb-9645-with-raspberry-pi-2/

author: Kjelt
author_rank: Super Contributor
timestamp: June 27, 2017, 02:03:12 pm
content: 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.

author: technix
author_rank: Super Contributor
timestamp: June 28, 2017, 01:49:35 am
content: Quote from: Kjelt on June 27, 2017, 12:06:28 pmMake 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.

author: Kjelt
author_rank: Super Contributor
timestamp: June 28, 2017, 07:52:10 am
content: 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?

author: technix
author_rank: Super Contributor
timestamp: June 28, 2017, 09:46:36 am
content: Quote from: Kjelt on June 28, 2017, 07:52:10 amHere 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.

author: technix
author_rank: Super Contributor
timestamp: June 29, 2017, 12:52:25 am
content: Quote from: Kjelt on June 28, 2017, 07:52:10 amThe 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.