Some Intel and AMD CPUs support firmware based TPM (fTPM)
I wonder where do they save the keys.
Do you have related reference material?
Related
ThunderBolt firmware is stored in its own SPI flash and is updatable from the OS. The system's UEFI firmware is also able to access its configuration data in the flash - users are able to change the ThunderBolt Security Level (SL) from the firmware setup menu during pre-boot. This means there is definitely some way to access the ThunderBolt firmware via some UEFI protocol, but nothing I've tried seems to work.
What I've Tried
I'm able to successfully identify the ThunderBolt device based on its vendor ID and device ID using the EFI_PCI_IO_PROTOCOL.
I initially thought the firmware is an option ROM, so it should be accessible via EFI_PCI_IO_PROTOCOL.RomImage. However the value is 0. I then thought the Expansion ROM Base Address Register (XROMBAR) that's inside the PCI Configuration Space may have it. But the XROMBAR is also 0. Extracting the firmware by reading the SPI flash using a hardware programmer, I found that it doesn't have the option ROM's signatures of 0xAA55 and "PCIR" anywhere. So it seems like the firmware is not an option ROM.
I then thought it could be stored in a firmware volume and thus should be accessible via the EFI_FIRMWARE_VOLUME2_PROTOCOL. I searched through all the firmware volumes and found a few option ROM, but none of them belong to ThunderBolt (as seen from their vendor ID and device ID).
Background
I was looking at the ThunderSpy exploit and the report states that the ThunderBolt firmware is not verified during boot. I thought this was unusual since my thinking then was that the firmware should be an option ROM, and option ROMs must be signed and verified by Secure Boot during every boot. From my findings so far, it seems like the firmware isn't an option ROM and is most likely executed directly on the ThunderBolt controller chip and not on the CPU, hence it is outside the purview of Secure Boot. I'm trying to programmatically access the firmware so as to see if there are ways to defend against ThunderSpy-like attacks where malicious modifications were made to the firmware.
I'm working on an embedded system running linux for embedded.
The HW has TPM chip. I've made some preparations, I installed the tpm2-tss and tpm2-tools sw libs and I've test them by hashing some data with the TPM. Its worked.
The system is implementing some RF protocol and transmit messages.
The messages are encrypted using AES128 with a secret key that each device have.
I want to use the TPM capabilities to store the key securely on the device and to encrypt the messages before I send them.
I know that the TPM HW is limited, but the data traffic is very low, so I don't see any issue with encrypting the data with the TPM.
There is a lot of information about the TPM, but all this information made me more confused. I need some guidelines and a simple explanation to help me with my needs.
From what I've read the TPM uses a secret internal key to encrypt data and store it on the system external memory. So i'm guess I need to use this feature to encrypt the device key and store it.
I didn't understand how I address my key after that and how I "tell" the TPM to encrypt some data with this key.
I am same problems with TPM2. O TPM2 is so much confused to use tpm2-tools. I recommend use clevis-encrypt tpm2 to abstract complexity of encrypt and decrypt.
If u have news with use TPM2 to sealing boot. I thank if u share here
I'm currently doing some research about ARM's TrustZone, e.g. here: ARM information center. As far as I understand, with TrustZone a secure environment based on the AMBA AXI bus can be created.
On ARM website it says: "This concept of secure and non-secure worlds extends beyond the processor to encompass memory, software, bus transactions, interrupts and peripherals within an SoC." I read that peripherals can be connected to TrustZone via the NonSecure-bit of the AMBA AXI bus (The extra signal is used to differentiate between trusted and non-trusted requests).
1) What, except the extra pin of AMBA AXI bus, is the TrustZone specific hardware in a SoC with TrustZone?
2) Is it possible to connect an external non-volatile memory (e.g. Flash) or a partition of it to TrustZone with access to secure world (via external memory interface and -then internal- the AXI bus)? If no, how are secrets (as keys) stored to be used in the secure world (with help of fuses??)? If yes, how is it prevented that a Flash including malicious code is connected?
3) Is it possible to implement code to the secure world as a customer of a chip vendor (e.g. TI or NXP), either before or after the chip left the factory?
Thank you for your answers.
TrustZone is a set of standards released by ARM. It gives OEM (embedded software programmers) and SOC vendors some tools to make a secure solution. These have different needs depending on what needs to be secured. So each SOC will be different. Some SOC manufacturers will try to compete on the same security application, but they will still differentiate.
1) What, except the extra pin of AMBA AXI bus, is the TrustZone specific hardware in a SoC with TrustZone?
Anything that the vendor wants. The GIC (ARMv7-A) interrupt controller, the L1 and L2 controllers, and MMU are all TrustZone aware peripherals in most Cortex-A CPUs. These are designed by ARM and implemented in the SOC. As well, there are various memory partitioning/exclusion devices which can be placed in between a peripheral and the SOC. Examples are the NIC301 and various proprietary BUS interconnect technology.
Other hardware may include physical tampers, voltage and temperature monitoring, clock monitoring and cryptography accelerators.
2) Is it possible to connect an external non-volatile memory (e.g. Flash) or a partition of it to TrustZone with access to secure world (via external memory interface and -then internal- the AXI bus)? If no, how are secrets (as keys) stored to be used in the secure world (with help of fuses??)? If yes, how is it prevented that a Flash including malicious code is connected?
As the above alludes, chips like the NIC301 can physically partition AXI peripherals.See image below Part of any TrustZone solution is some secure boot mechanism. All CPU will boot in the secure world. The secure boot mechanism may vary. For instance, a one time programmable ROM might be appropriate for some applications. Many have programmable fuses with a public/private key mechanism implemented in SOC ROM. The SOC ROM boot software will verify that the image in flash is properly signed by whoever burned the one time fuses.
This OEM image can set-up many TrustZone peripherals, most of which will have a lock bit. Once set, registers in the peripherals can not be changed until the next hard boot.
3) Is it possible to implement code to the secure world as a customer of a chip vendor (e.g. TI or NXP), either before or after the chip left the factory?
Yes, this is the secure boot mechanism. It is not specified in the ARM TrustZone documents on how code will be secured. If you manufacture the chip and have on-chip ROM with a MESH layer protecting it maybe sufficient for secure boot. However, TI and NXP will implement a public/private key mechanism and verify that only software signed by an OEM can be loaded. This OEM software can have bugs (and possibly the ROM loader by the SOC vendor), but at least it is possible to create a secure boot chain.
With public key, even complete access to the chip will only allow an attacker to load previously released software from the OEM. Some solutions may have revocation mechanisms as well to prevent previously released software from being used.
See: trust-zone
Typical ARM bus
ARM partition checker
Handling ARM TrustZone
I'm trying to get a good understanding of how a graphics adapter works and how a graphics driver is built.
So far I've read intel's (very technical) documentation, looked into linux i915 drm driver, and searched the net for more information for weeks.
The platform I'm testing with is a Minnowboard MAX (64-bit Intel®Atom™ E38xx Series SoC - valleyview graphics) and I have the tools and knowledge to change and flash the UEFI firmware (using EDK2 - https://github.com/tianocore/tianocore.github.io/wiki/MinnowBoard). So my questions are:
1) I've read that issuing commands to the graphics adapter happens via the ringbuffer (by issuing batch buffers), is a ringbuffer initialized in the firmware found in the git repository?
2) If not than what are the steps to initialize one?
3) If it is initialized and the console output is generated with the help of the graphics adapter - how can I find the address to which I should write the batch buffers?
Any help or pointers would be greatly appreciated.
I trying to learn DMA for device drivers with PCI/PCIe devices, and my platform is linux/bsd. I have found quite a few simple PCI boards for training (such as simple digital I/O boards), but none have hardware complex enough to handle DMA. Is anyone on Stackoverflow aware of a PCI/PCIe card with some sort of microprocessor or mcirocontroller that I could program with open-source tools like gcc (e.g. PowerPC, 68HC11, Atmel, 8051, etc.)??
Of course the kicker is low cost...sub USD 300.00 if possible.
I DO NOT WANT an FPGA-based board, because that requires a Windows workstation (usually) for programming the FPGA, as well as all of the time required for creating and working with a PCI/PCIe IP core in the FPGA. Basically, I don't want to spend my time working on the FPGA; I want to work on the device driver! This may be my only option though...
If you don't want to use FPGA, then you have to find a board that has enough info for you to be able to communicate with the PCIe interface of it. Not that many boards come with HW interface document, but if you want or can do this without documentation, you can use one of these boards:
Alibaba 4 Channel MIDI GAME port 3D
Same board on E-bay Alternative 2 on e-bay
You can also get a bit more advanced board like this one, but then you need to know how to communicate with their chipset.
Alibaba 4CH PCIe HDMI Video Capture Card here
If you change your mind for the FPGA, I would really recommend the Altera PCIe board that comes with a reference design and the bit file already per-programmed on the board. It is much more expensive than those, but the biggest benefit is that you have full documentation of the PCIe interface:
Altera Cyclone IV GX Transceiver Starter Kit
Here is the info about their reference design:
Altera PCIe reference design
Hope you find what you are looking for here.