Once an encrypted volume is mounted, it is subject to the standard operating system enforced file system protections. An encrypted volume that is automatically mounted without user intervention will offer no protection if an attacker is allowed to override the kernel command line and start an interactive shell without having to log in, for example. LUKS ensures data confidentiality at rest.
LUKS stores setup information in the partition header to aid easy migration. LUKS volumes can be automatically mounted, and the encryption passphrase can be supplied interactively default and or specified as key file command line argument. The cryptsetup user-space utility aids creating and managing LUKS volumes. At this point you have set up the LUKS volume and it should display a warning about overwriting the data. Open the LUKS volume by authenticating with the disk. Observe that the sensitive data is no longer visible in the encrypted disk image:.
The biggest issue with this method of encrypting the disk volume is that LUKS protections are easily subverted if the passphrase or key file is stored in plain text on disk. Thus, many LUKS implementations interactively prompt for the passphrase. This solution is unworkable for many Internet of Things IoT and embedded scenarios due to the lack of a human at a keyboard. An effective alternative to human input is to seal the passphrase on a security token that anchors to the platform, like a TPM.
Since auto-mounting requires providing a passphrase or key to cryptsetup at runtime without user intervention, it must as some point be available in the clear. A method is needed to encrypt the passphrase or key until it is needed at runtime to decrypt the volume. Such a method must also protect against the case where the disk is separated from the system into which it was installed.
This mechanism is TPM. Create and persist a sealing object and use it to seal a random byte sequence as the disk key:. An attacker now additionally needs the TPM on the platform along with the disk to access the data since the decryption key isn't on the disk—it is safely stored on the TPM anchored to the specific platform. This improved solution will protect against offline attacks through cloning or physical theft of the encrypted disk.
It may still be possible, however, for an attacker to boot a system from alternative boot media, perform the above commands, and retrieve the secret needed to decrypt the LUKS volume. What is needed is an authentication mechanism that anchors to trusted system state. TPM platform configuration registers PCRs are used to protect against the scenario where an attacker alters the system boot parameters or boots to an operating system of their choice in order to access sensitive data.
Effective use of TPM PCRs requires the cooperation of the system firmware, boot loaders, operating system kernel, and applications. PCR0, for example, contains measurements of the system firmware and BIOS, but not the operating system boot loader or kernel. A consequence of using PCR0 and only PCR0 is that this example would only protect against a firmware replacement attack, provided the original firmware made measurements properly, and provided the replacement firmware does not forge measurements to the TPM—an attack that requires a separate mitigation.
In practice, an effective PCR set must be sufficiently complete to attest the currently running code and any code that has run beforehand that the designer deems security-critical. PCR usage during and after operating system boot is operating system specific. Now replace the seal object in the TPM non-volatile memory protecting the disk encryption secret with a new one that adds the pcr policy we just created as an authentication mechanism to access the sealed secret:.
Now try to mount the encrypted disk again except this time the secret is sealed inside a TPM object whose unsealing operation can only be accessed by satisfying the PCR policy. In other words, authenticating by virtue of intended system software state being unchanged as reflected by the PCR value.
However, for the purpose of demonstrating flexible PCR in a later section we will make a copy of the unsealed secret:. To prevent further unsealing, PCR0 will be extended. This will cause PCR0 to hold a different value, much like it would during a firmware replacement attack. This will cause a failed policy check and thus a failed unsealing attempt.
In this example, applying a firmware update to the system could render the encrypted data inaccessible because PCR0 represents a specific version of the firmware. Why these steps? Well, first of all, like any other device listed in the BIOS you can decide if you want to use or not. Initializing it means you will tell the TPM chip you own the device and therefor you are allowed to compute against it.
Owning a device will result in generating an Owner Password on the chip. This will allow us to use its features. So, basically, there is a mummy in front of the only entrance into the pyramid, asking you for the secret word, before it allows you in. In order to use or read anything inside the TPM chip, you need to authenticate first, this with your Owner Password, to proof you own this device. Only one Owner can exist, resulting in one Owner Password.
This is the gatekeeper. The Owner Password is also non-exportable. Once it is set you cannot retrieve it anymore. If you try too many times telling the mummy the wrong secret word, the mummy gets angry and kicks you out, closing that one single door for x amount of time. When you do your exam for Microsoft Certification you need to show your ID card Crypto , that will allow you into a secure room to do your exam.
In this case a mathematical exam. When signing up to start your exam, you need to read out your IDCard when it is digital. This one will make sure the mummy behind the desk can read your IDCard. Basically here, the mummy can already read a part of your IDCard, but needs to decypher a bit more so the mummy can validate if this one is not a fake. Game passed! This makes your information a lot more secure. On the down side, it makes the TPM your single point of failure and prone to attacks.
This generator is responsible to generate your Challenge. Using an RNG gives you the advantage to prevent replay of old signature. One pitfall about this treasure room, you will receive a few keys allowing you to access the jewels in the treasure room but you cannot take them out of the room, because they are glued to the shiny desk and floors…. If he signs your request everyone in the kingdom needs to obey the request.
It should indicate that the Trusted Building Block TBB design and implementation has been accepted according to the evaluation guidelines. They typically contain the name of the evaluator, platform manufacturer, the model number and version of the platform, the TPM manufacturer name, TPM model number and version or stepping and a pointer to the location of the TPM and platform conformance documentation.
The Conformance Credential does not contain privacy sensitive information or information that can be used to uniquely identify a specific platform. Platform Credential The Platform Credential is issued by the platform manufacturer, vendor or an independent entity.
It should provide evidence, that the platform contains a TPM as described by the Endorsement Credential. The Platform Credential contains the name of the platform manufacturer, the platform model number and version and references to the Endorsement Credential and the Conformance Credentials. The Platform Credential is privacy sensitive since it contains information that can be used to uniquely identify a specific platform.
Manipulations of the SML will be detected because the digest of the original sequence is securely stored inside the TPM.
The process of modifying a PCR value is called extending a PCR and ensures that previous will not be ignored and the order of operations is preserved.
The content of the PCRs can be used for verifiable attestation see section 3. Validation Credentials are digital certificates issued by hard- or software manufacturers that provide measurable components like video and disk storage adapters, memory controllers, processors or software or other qualified validation entities.
They contain the validation entity name, component manufacturer name, component model number, version or stepping and digitally signed reference measurement values taken in a clean-room environment when the component is believed to work properly. The verification of a platform configuration state requires the re-computation of the measurement digest using the reference measurements from the Validation Credentials and a simple comparison of the resulting digest value with the actual content of the PCR.
Chain of Trust. As already mentioned, a trusted platform subsequently reports integrity measurement information to the TPM. The idea is that each firm- or software component that is to be loaded or executed is measured before it is started. The result of this check, a message digest, is reported to the TPM in a cryptographically secure manner.
Once the value has been submitted to the TPM, it cannot be changed. This means that any change or manipulation of the software state can be recognized since malicious software cannot hide itself by manipulating PCR values or the SML. This implies that the instructions that start the chain of measurements must be trusted which means that they have to function as expected.
Ideally the CRTM would reside in the TPM to profit from its tamper-resistance but due to architectural requirements of the specific platform it might also be located in another device like the BIOS of the PC platform which can hardly be manipulated from an remote adversary and should be trusted.
Fig4: Chain of Trust. Trust Assumptions. This means that they have to behave in a way that does not compromise the goals of trusted platforms. Binding means that a message can be bound to a certain TPM and platform using encryption. When encrypting a message with an asymmetric encryption scheme, the sender uses the public key of the recipient to encrypt a message. The recipient is then able to decrypt the ciphertext with his corresponding private key which can be managed by a TPM.
If this private key is a non-migratable key then only the TPM that generated it is able to use the key and thus decrypt the message. Therefore the message is bound to the TPM that protects the corresponding private key.
0コメント