Welcome to the November of posts,
Today: Using a Trusted Platform Module for endpoint device security in AWS IoT Greengrass!
The credits goes to:
The Infineon guys for build an example for use a TPM and pkcs11 in an AWS IoT greengrass environment and share it on github[1].
And Krishnan Ganapathy from amazon web services writes a blog article about it[2].
Thanks for the great work!
Bye for now!
Paul
[1]
https://github.com/Infineon/amazon-greengrass-hsi-optiga-tpm
[2]
https://aws.amazon.com/de/blogs/iot/using-a-trusted-platform-module-for-endpoint-device-security-in-aws-iot-greengrass/
Welcome!
The last time i get some questions about the chipselect configs for the module.
How you could move the default config from the LT-TPM CS1 to CS0.
If you want to use the TPM with CS0 you must change (resolder) the position of the 0Ohm Resistor to the open pads.
You'll see the difference if you open both pdfs:
letstrust-v2.2.placement.cs1.pdf
letstrust-v2.2.placement.cs0.pdf
If you don’t want to compile your device-tree-overlay by yourself, copy the tpm-slb9670-cs0.dtbo [1] to /boot/overlays/ and load the dtbo in the /boot/config.txt
over the setting dtoverlay=tpm-slb9670-cs0
If you want to decompile change and recompile the devicetree for the slb9670 for yourself:
1) sudo apt-get install device-tree-compiler
2) dtc -I dtb -O dts -o /mnt/boot/overlays/tpm-slb9670.dts /mnt/boot/overlays/tpm-slb9670.dtbo
3) cp mnt/boot/overlays/tpm-slb9670.dts /mnt/boot/overlays/tpm-slb9670-cs0.dts
4) dtc -I dts -O dtb -o /mnt/boot/overlays/tpm-slb9670-cs0.dtbo /mnt/boot/overlays/tpm-slb9670-cs0.dts
[2][3]
Bye for now!
Paul
[1]
tpm-slb9670-cs0.dtbo
[2]
tpm-slb9670.dts
[3]
tpm-slb9670-cs0.dts
PS: this will only work on the Raspberry Pis 0-4
Hello!
I've updated the pcb-design,[1]
Now we have the revision 2.2!
Changes from rev 2.0 to rev 2.2 [2]
Add 100nF capacitor on the RESET line of the TPM for a better POR (Power On Reset) behavior..
Change pad 1 from octagon to square, for better identify pin 1.
Add tiny labels on every pin on the bottom side (without MISO/MOSI/CLK, no place for the labels on these pins)
I added a legend in the schematics, for better reference if you want to use the TPM on your own Hardware design.
Placement and the schematic you will find in the right column.
Bye for now
Paul
[1] two months ago
[2] Revision 2.1 was never produced.
Hello again,
in September this year I get mail from Luke Hinds, with some questions about the compatibility from LetsTrust-TPMs and RaspberryPis to check if will work for his project.
Now I proudly happy to link to this hilarious Project:
keylime.dev
Quote from Keylime.dev:
“Keylime is about making TPM technology accessible for developers and users. It handles the complexity, you drive the use case!”
Thanks to Luke and all contributors of Keylime!
Bye for now,
Paul
Welcome back!
no I´m not dead, \o/ ,
but the vulnerability ---TPM-fail--- need my highest attention today.
The good news: LetsTrust-TPMs are not affected!
But I'm not a friend of “hiding” information:
The SLB9670 that we used on our PCBs has the same certification levels on Common Criteria EAL4+ and FIPS 140-2 as the fTPM from Intel and the ST33 from STM.
If I get new information of the Chip on our LetsTrust-TPMs, I'll post an update here.
UPDATE: Quote from
http://tpm.fail/tpmfail.pdf
Our analysis reveals that Intel fTPM and the dedicated TPM
manufactured by STMicroelectronics leak information about
the secret nonce in elliptic curve signature schemes, which
can lead to efficient recovery of the private key. As discussed
in Section 6, we also observe non-constant-time behavior by
the TPM manufactured by Infineon which does not appear
to expose an exploitable vulnerability.
Bye for now
Paul
UPDATE: Reference:
tpm.fail
Reference:
zdnet.com
CVE-2019-11090 and impacts Intel's Platform Trust Technology (PTT).
CVE-2019-16863 and impacts the ST33 TPM chip made by STMicroelectronics.
