Windows 11 Now Enforces the Same System Requirements in Virtual Machines - Including TPM

[Guest]

3 minutes ago, LAwLz said:

In a stand alone TPM (not fTPM) the seed key is burn into the hardware and does not have to be stored into memory at all. 

I was talking about fTPM (Sorry for my lack of context)

[leadeater]

9 hours ago, jagdtigger said:

Since the chip storing the FW is read only the only place it can store is the battery backed ram on the mobo. If you clear that i think the rsa key goes with it. Dont have the time and hw to test it though....

A TPM/fTPM ban doesn't actually ban the RSA key, which is protected anyway so you could never ban it because it's not readable. The key being talked about is for internal TPM usage only, not the user derived keys for drive encryption (BitLocker) etc.

 

Quote

6.2 Secure World Hardware Fuses We required a set of hardware fuses that can be read from the secure world only. These fuses are provisioned with a hard-to-guess, unique-per-device number. This number is used as a seed in deriving additional secret keys used by the fTPM. Section 9 will describe in-depth how the seed is used in deriving secret fTPM keys, such as the secure storage key (SSK)

 

Quote

The combination of encryption, the RPMB, and hardware fuses is sufficient to build trusted storage for the TEE. Upon booting the first time, TEE generates a symmetric RPMB key and programs it into the RPMB controller. The RPMB key is derived from existing keys available on the platform. In particular, we construct a secure storage key (SSK) that is unique to the device and derived as following: SSK := KDF(HF,DK,UUID) (1) where KDF is a one-way key derivation function, HF is the value read from the hardware fuses, DK is a device key available to both secure and normal worlds, and UUID is the device’s unique identifier. The SSK is used for authenticated reads and writes of all TEE’s persistent state (including the fTPM’s state) to the device’s flash memory. Before being persisted, the state is encrypted with a key available to TrustZone only. Encryption ensures that all fTPM’s state remains confidential and integrity protected. The RPMB’s authenticated reads and writes ensure that fTPM’s state is also resilient against replay attacks.

https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_raj.pdf

 

@WickedThunder86A TPM rest only resets user generated keys etc, it won't actually wipe the SSK and the HF, DK and UUID are hardware unique and nonvolatile. Disk encryption wouldn't be implemented in such a way that if the device lost power to everything that it would unreadable forever again.

 

I also believe even if you were to generate the key again it would result in the same key because of the way the SSK is generated.

 

8 hours ago, WickedThunder86 said:

Having it under a permissive license like BSD,MIT,Apache doesn`t mean it`s deriatives need to be open source as well (You need to have copyleft license like GNU GPL or GNU LGPL to force it`s deriatives to be free and open source as well). So, Since the license is permissive the vendors who spefically design those TPM`s don`t need to share  the code so, the concept of security through obscurity applies to TPM as you will never know what data of yours they are sending to the NSA.

One of the primary issues with TPM 1.2 was that there was no reference specification which lead to many problems. This is why TPM 2.0 has a reference specification and implementation so while yes each vendor application of it will be code unique as to work with their fTPM implementation (Intel PTT, AMD PSP ARM TrustZone) they all have to function the same. None of them can implement anything outside of the TPM 2.0 spec and all function must conform to the TPM 2.0 spec.

 

Neither could a TPM send anything anywhere, that would actually be impossible. Namely because it literally can't do that and additionally the TPM doesn't store anything that would be of any use to anyone without the SSK which cannot be read. I guess you could try and argue any of the vendors could go outside the fTPM reference and do something funky but no security research has found anything like that at all.

 

8 hours ago, LAwLz said:

In a stand alone TPM (not fTPM) the seed key is burn into the hardware and does not have to be stored into memory at all. 

Same is effectively true for fTPM as well anyway. We are talking about banning TPM hardware IDs not actually the RSA key (SSK) and those can't be changed.

[StDragon]

1 hour ago, leadeater said:

We are talking about banning TPM hardware IDs not actually the RSA key (SSK) and those can't be changed.

With regards to fTPM, is the hardware ID in the CPU, or MB? I would think CPU, no?

[leadeater]

4 hours ago, StDragon said:

With regards to fTPM, is the hardware ID in the CPU, or MB? I would think CPU, no?

Motherboard, it's part of the chipset and is known as Intel Platform Trusted Technology. Intel TXT which is part of secure boot uses the fTPM.

[StDragon]

38 minutes ago, leadeater said:

Motherboard, it's part of the chipset and is known as Intel Platform Trusted Technology. Intel TXT which is part of secure boot uses the fTPM.

Ditto for the AMD fTPM?

[leadeater]

29 minutes ago, StDragon said:

Ditto for the AMD fTPM?

I think for AMD it is in the CPU.

 

Quote

The AMD Platform Security Processor (PSP), officially known as AMD Secure Technology, is a trusted execution environment subsystem incorporated since about 2013 into AMD microprocessors.[1] According to an AMD developer's guide, the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any suspicious activity or events and implementing an appropriate response".[2]

https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor

 

Quote

AMD Secure Technology™

The AMD Secure Processor™ (formerly known as the Platform Security Processor [PSP]) is a dedicated hardware security subsystem that runs independently from the platform's main core processors and is integrated into the SoC. It provides an isolated environment in which security-sensitive components can run without being affected by the software running as the main system workload. The PSP can execute system workloads as well as workloads provided by trusted third parties. Although system workloads are preinstalled and provide SoC-specific security services, the system administrator has complete control over whether and which third-party workloads are installed on the PSP. The PSP is made up of the following components:

• Dedicated 32-bit microcontroller (ARM with TrustZone technology)

• Isolated on-chip ROM and SRAM

• DRAM carved out via hardware barrier and encrypted

• Access to system memory and resources

• Secure off-chip NV storage access for firmware and data

• Platform-unique key material

• Hardware logic for secure control of CPU core boot

• Cryptographic coprocessor (CCP)

The PSP uses the ARM TrustZone architecture, as described in the section on ARM TrustZone, but there are some differences: rather than being a virtual core, the PSP is a physically disparate core integrated into the SoC that has dedicated SRAM and dedicated access to the CCP. The PSP provides the immutable hardware root of trust that can be used as the basis for optionally providing the chain of trust from the hardware up to the OS.

The CCP is made up of a random number generator (RNG), several engines to process standard cryptographic algorithms (AES, RSA, and others depending on processor model), and a key storage block. The key storage block contains two key storage areas: one dedicated to storing system keys that can be used by privileged software but that are never readable; and the other into which keys can be loaded, used, and evicted during normal operation by software running either on the PSP or on the main OS.

 

During boot, SoC-unique e-fused keys are distributed to the CCP system key storage block.

https://ebrary.net/24869/computer_science/secure_technology