A short introduction to TPMs
May. 6th, 2013 11:50 pm![[personal profile]](http://s.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I've been working on TPMs lately. It turns out that they're moderately awful, but what's significantly more awful is basically all the existing documentation. So here's some of what I've learned, presented in the hope that it saves someone else some amount of misery.
All of this means that the keys are tied to a system, which is great for security. An attacker can't obtain the decrypted keys, even if they have a keylogger and full access to your filesystem. If I encrypt my laptop's drive and then encrypt the decryption key with the TPM, stealing my drive won't help even if you have my passphrase - any other TPM simply doesn't have the keys necessary to give you access.
That's fine for keys which are system specific, but what about keys that I might want to use on multiple systems, or keys that I want to carry on using when I need to replace my hardware? Keys can optionally be flagged as migratable, which makes it possible to export them from the TPM and import them to another TPM. This seems like it defeats most of the benefits, but there's a couple of features that improve security here. The first is that you need the TPM ownership password, which is something that's set during initial TPM setup and then not usually used afterwards. An attacker would need to obtain this somehow. The other is that you can set limits on migration when you initially import the key. In this scenario the TPM will only be willing to export the key by encrypting it with a pre-configured public key. If the private half is kept offline, an attacker is still unable to obtain a decrypted copy of the key.
TPMs have a series of Platform Configuration Registers (PCRs) that are used to record system state. These all start off programmed to zero, but applications can extend them at runtime by writing a sha1 hash into them. The new hash is concatenated to the existing PCR value and another sha1 calculated, and then this value is stored in the PCR. The firmware hashes itself and various option ROMs and adds those values to some PCRs, and then grabs the bootloader and hashes that. The bootloader then hashes its configuration and the files it reads before executing them.
This chain of trust means that you can verify that no prior system component has been modified. If an attacker modifies the bootloader then the firmware will calculate a different hash value, and there's no way for the attacker to force that back to the original value. Changing the kernel or the initrd will result in the same problem. Other than replacing the very low level firmware code that controls the root of trust, there's no way an attacker can replace any fundamental system components without changing the hash values.
TPMs support using these hash values to decide whether or not to perform a decryption operation. If an attacker replaces the initrd, the PCRs won't match and the TPM will simply refuse to hand over the secret. You can actually see this in use on Windows devices using Bitlocker - if you do anything that would change the PCR state (like booting into recovery mode), the TPM won't hand over the key and Bitlocker has to prompt for a recovery key. Choosing which PCRs to care about is something of a balancing act. Firmware configuration is typically hashed into PCR 1, so changing any firmware configuration options will change it. If PCR 1 is listed as one of the values that must match in order to release the secret, changing any firmware options will prevent the secret from being released. That's probably overkill. On the other hand, PCR 0 will normally contain the firmware hash itself. Including this means that the user will need to recover after updating their firmware, but failing to include it means that an attacker can subvert the system by replacing the firmware.
This is where Remote Attestation comes in. Rather than keep any secrets on the local TPM, the TPM can assert to a remote site that the system is in a specific state. The remote site can then make a policy determination based on multiple factors and decide whether or not to hand over session decryption keys. The idea here is fairly straightforward. The remote site sends a nonce and a list of PCRs. The TPM generates a blob with the requested PCR values, sticks the nonce on, encrypts it and sends it back to the remote site. The remote site verifies that the reply was encrypted with an actual TPM key, makes sure that the nonce matches and then makes a policy determination based on the PCR state.
But hold on. How does the remote site know that the reply was encrypted with an actual TPM? When TPMs are built, they have something called an Endorsement Key (EK) flashed into them. The idea is that the only way to have a valid EK is to have a TPM, and that the TPM will never release this key to anything else. There's a couple of problems here. The first is that proving you have a valid EK to a remote site involves having a chain of trust between the EK and some globally trusted third party. Most TPMs don't have this - the only ones I know of that do are recent Infineon and STMicro parts. The second is that TPMs only have a single EK, and so any site performing remote attestation can cross-correlate you with any other site. That's a pretty significant privacy concern.
There's a theoretical solution to the privacy issue. TPMs never actually sign PCR quotes with the EK. Instead, TPMs can generate something called an Attestation Identity Key (AIK) and sign it with the EK. The OS can then provide this to a site called a PrivacyCA, which verifies that the AIK is signed by a real EK (and hence a real TPM). When a third party site requests remote attestation, the TPM signs the PCRs with the AIK and the third party site asks the PrivacyCA whether the AIK is real. You can have as many AIKs as you want, so you can provide each service with a different AIK.
As long as the PrivacyCA only keeps track of whether an AIK is valid and not which EK it was signed with, this avoids the privacy concerns - nobody would be able to tell that multiple AIKs came from the same TPM. On the other hand, it makes any PrivacyCA a pretty attractive target. Compromising one would not only allow you to fake up any remote attestation requests, it would let you violate user privacy expectations by seeing that (say) the TPM being used to attest to HolyScriptureVideos.com was also being used to attest to DegradingPornographyInvolvingAnimals.com.
Perhaps unsurprisingly (given the associated liability concerns), there's no public and trusted PrivacyCAs yet, and even if they were (a) many computers are still being sold without TPMs and (b) even those with TPMs often don't have the EK certificate that would be required to make remote attestation possible. So while remote attestation could theoretically be used to impose DRM in a way that would require you to be running a specific OS, practical concerns make it pretty difficult for anyone to deploy that at any point in the near future.
Things get more interesting in more niche cases. Corporations can bind VPN keys to corporate machines, making it possible to impose varying security policies. Intel use the TPM as part of their anti-theft technology on education-oriented devices like the Classmate. And in the cloud, projects like Trusted Computing Pools use remote attestation to verify that compute nodes are in a known good state before scheduling jobs on them.
[1] Ranging from 8-bit things that are better suited to driving washing machines, up to full ARM cores
[2] "Low Pin Count", basically ISA without the slots.
[3] Loading a key and decrypting a 5 byte payload takes 1.5 seconds on my laptop's TPM.
What is a TPM?
TPMs are devices that adhere to the Trusted Computing Group's Trusted Platform Module specification. They're typically microcontrollers[1] with a small amount of flash, and attached via either i2c (on embedded devices) or LPC[2] (on PCs). While designed for performing cryptographic tasks, TPMs are not cryptographic accelerators - in almost all situations, carrying out any TPM operations on the CPU instead would be massively faster[3]. So why use a TPM at all?Keeping secrets with a TPM
TPMs can encrypt and decrypt things. They're not terribly fast at doing so, but they have one significant benefit over doing it on the CPU - they can do it with keys that are tied to the TPM. All TPMs have something called a Storage Root Key (or SRK) that's generated when the TPM is initially configured. You can ask the TPM to generate a new keypair, and it'll do so, encrypt them with the SRK (or another key descended from the SRK) and hand it back to you. Other than the SRK (and another key called the Endorsement Key, which we'll get back to later), these keys aren't actually kept on the TPM - the running OS stores them on disk. If the OS wants to encrypt or decrypt something, it loads the key into the TPM and asks it to perform the desired operation. The TPM decrypts the key and then goes to work on the data. For small quantities of data, the secret can even be stored in the TPM's nvram rather than on disk.All of this means that the keys are tied to a system, which is great for security. An attacker can't obtain the decrypted keys, even if they have a keylogger and full access to your filesystem. If I encrypt my laptop's drive and then encrypt the decryption key with the TPM, stealing my drive won't help even if you have my passphrase - any other TPM simply doesn't have the keys necessary to give you access.
That's fine for keys which are system specific, but what about keys that I might want to use on multiple systems, or keys that I want to carry on using when I need to replace my hardware? Keys can optionally be flagged as migratable, which makes it possible to export them from the TPM and import them to another TPM. This seems like it defeats most of the benefits, but there's a couple of features that improve security here. The first is that you need the TPM ownership password, which is something that's set during initial TPM setup and then not usually used afterwards. An attacker would need to obtain this somehow. The other is that you can set limits on migration when you initially import the key. In this scenario the TPM will only be willing to export the key by encrypting it with a pre-configured public key. If the private half is kept offline, an attacker is still unable to obtain a decrypted copy of the key.
So I just replace the OS with one that steals the secret, right?
Say my root filesystem is encrypted with a secret that's stored on the TPM. An attacker can replace my kernel with one that grabs that secret once the TPM's released it. How can I avoid that?TPMs have a series of Platform Configuration Registers (PCRs) that are used to record system state. These all start off programmed to zero, but applications can extend them at runtime by writing a sha1 hash into them. The new hash is concatenated to the existing PCR value and another sha1 calculated, and then this value is stored in the PCR. The firmware hashes itself and various option ROMs and adds those values to some PCRs, and then grabs the bootloader and hashes that. The bootloader then hashes its configuration and the files it reads before executing them.
This chain of trust means that you can verify that no prior system component has been modified. If an attacker modifies the bootloader then the firmware will calculate a different hash value, and there's no way for the attacker to force that back to the original value. Changing the kernel or the initrd will result in the same problem. Other than replacing the very low level firmware code that controls the root of trust, there's no way an attacker can replace any fundamental system components without changing the hash values.
TPMs support using these hash values to decide whether or not to perform a decryption operation. If an attacker replaces the initrd, the PCRs won't match and the TPM will simply refuse to hand over the secret. You can actually see this in use on Windows devices using Bitlocker - if you do anything that would change the PCR state (like booting into recovery mode), the TPM won't hand over the key and Bitlocker has to prompt for a recovery key. Choosing which PCRs to care about is something of a balancing act. Firmware configuration is typically hashed into PCR 1, so changing any firmware configuration options will change it. If PCR 1 is listed as one of the values that must match in order to release the secret, changing any firmware options will prevent the secret from being released. That's probably overkill. On the other hand, PCR 0 will normally contain the firmware hash itself. Including this means that the user will need to recover after updating their firmware, but failing to include it means that an attacker can subvert the system by replacing the firmware.
What about using TPMs for DRM?
In theory you could populate TPMs with DRM keys for media playback, and seal them such that the hardware wouldn't hand them over. In practice this is probably too easily subverted or too user-hostile - changing default boot order in your firmware would result in validation failing, and permitting that would allow fairly straightforward subverted boot processes. You really need a finer grained policy management approach, and that's something that the TPM itself can't support.This is where Remote Attestation comes in. Rather than keep any secrets on the local TPM, the TPM can assert to a remote site that the system is in a specific state. The remote site can then make a policy determination based on multiple factors and decide whether or not to hand over session decryption keys. The idea here is fairly straightforward. The remote site sends a nonce and a list of PCRs. The TPM generates a blob with the requested PCR values, sticks the nonce on, encrypts it and sends it back to the remote site. The remote site verifies that the reply was encrypted with an actual TPM key, makes sure that the nonce matches and then makes a policy determination based on the PCR state.
But hold on. How does the remote site know that the reply was encrypted with an actual TPM? When TPMs are built, they have something called an Endorsement Key (EK) flashed into them. The idea is that the only way to have a valid EK is to have a TPM, and that the TPM will never release this key to anything else. There's a couple of problems here. The first is that proving you have a valid EK to a remote site involves having a chain of trust between the EK and some globally trusted third party. Most TPMs don't have this - the only ones I know of that do are recent Infineon and STMicro parts. The second is that TPMs only have a single EK, and so any site performing remote attestation can cross-correlate you with any other site. That's a pretty significant privacy concern.
There's a theoretical solution to the privacy issue. TPMs never actually sign PCR quotes with the EK. Instead, TPMs can generate something called an Attestation Identity Key (AIK) and sign it with the EK. The OS can then provide this to a site called a PrivacyCA, which verifies that the AIK is signed by a real EK (and hence a real TPM). When a third party site requests remote attestation, the TPM signs the PCRs with the AIK and the third party site asks the PrivacyCA whether the AIK is real. You can have as many AIKs as you want, so you can provide each service with a different AIK.
As long as the PrivacyCA only keeps track of whether an AIK is valid and not which EK it was signed with, this avoids the privacy concerns - nobody would be able to tell that multiple AIKs came from the same TPM. On the other hand, it makes any PrivacyCA a pretty attractive target. Compromising one would not only allow you to fake up any remote attestation requests, it would let you violate user privacy expectations by seeing that (say) the TPM being used to attest to HolyScriptureVideos.com was also being used to attest to DegradingPornographyInvolvingAnimals.com.
Perhaps unsurprisingly (given the associated liability concerns), there's no public and trusted PrivacyCAs yet, and even if they were (a) many computers are still being sold without TPMs and (b) even those with TPMs often don't have the EK certificate that would be required to make remote attestation possible. So while remote attestation could theoretically be used to impose DRM in a way that would require you to be running a specific OS, practical concerns make it pretty difficult for anyone to deploy that at any point in the near future.
Is this just limited to early OS components?
Nope. The Linux kernel has support for measuring each binary run or each module loaded and extending PCRs accordingly. This makes it possible to ensure that the running binaries haven't been modified on disk. There's not a lot of distribution infrastructure for setting this up, but in theory a distribution could deploy an entirely signed userspace and allow the user to opt into only executing correctly signed binaries. Things get more interesting when you add interpreted scripts to the mix, so there's still plenty of work to do there.So what can I actually use a TPM for?
Drive encryption is probably the best example (Bitlocker does it on Windows, and there's a LUKS-based implementation for Linux here) - while in theory you could do things like use your TPM as a factor in two-factor authentication or tie your GPG key to it, there's not a lot of existing infrastructure for handling all of that. For the majority of people, the most useful feature of the TPM is probably the random number generator. rngd has support for pulling numbers out of it and stashing them in /dev/random, and it's probably worth doing that unless you have an Ivy Bridge or other CPU with an RNG.Things get more interesting in more niche cases. Corporations can bind VPN keys to corporate machines, making it possible to impose varying security policies. Intel use the TPM as part of their anti-theft technology on education-oriented devices like the Classmate. And in the cloud, projects like Trusted Computing Pools use remote attestation to verify that compute nodes are in a known good state before scheduling jobs on them.
Is there a threat to freedom?
At the moment, probably not. The lack of any workable general purpose remote attestation makes it difficult for anyone to impose TPM-based restrictions on users, and any local code is obviously under the user's control - got a program that wants to read the PCR state before letting you do something? LD_PRELOAD something that gives it the desired response, or hack it so it ignores failure. It's just far too easy to circumvent.Summary?
TPMs are useful for some very domain-specific applications, drive encryption and random number generation. The current state of technology doesn't make them useful for practical limitations of end-user freedom.[1] Ranging from 8-bit things that are better suited to driving washing machines, up to full ARM cores
[2] "Low Pin Count", basically ISA without the slots.
[3] Loading a key and decrypting a 5 byte payload takes 1.5 seconds on my laptop's TPM.
![[identity profile]](http://s.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-05-07 07:17 pm (UTC)Where does the time go? Seriously.
no subject
Date: 2013-05-07 07:25 pm (UTC)how 2 tell if my PC contains a TPM?
Date: 2013-05-07 08:21 pm (UTC)Re: how 2 tell if my PC contains a TPM?
Date: 2013-05-07 09:13 pm (UTC)Re: how 2 tell if my PC contains a TPM?
Date: 2013-05-08 11:44 am (UTC)Also, what would stop someone having two PCs, one clean which answer nicely all TPM requests, and one "bad" which intercept those requests and relay them?
Re: how 2 tell if my PC contains a TPM?
Date: 2013-05-08 02:06 pm (UTC)No, you need to run rngd.
Nothing - it would just be like having a TPM connected via IP rather than i2c or LPC.
what about dynamic root of trust?
Date: 2013-05-07 09:15 pm (UTC)Re: what about dynamic root of trust?
Date: 2013-05-07 09:50 pm (UTC)ThinkPad fingerprint reader?
Date: 2013-05-07 10:08 pm (UTC)Re: ThinkPad fingerprint reader?
Date: 2013-05-07 10:15 pm (UTC)Re: ThinkPad fingerprint reader?
Date: 2013-05-16 08:24 am (UTC)With Linux the BIOS/ATA unlock all happen the same. There is libfprint which will let you login with a fingerprint scan, but that means PAM doesn't ever see a textual password. If your keychain is encrypted then you end up prompted to enter your password anyway. The only way to prevent that is not encrypting the keychain!
The fingerprint hardware and software is made by authentec who didn't care about non-Windows operating systems. Apple bought them a while back.
Let the TPM do the enforcement...
Date: 2013-05-08 12:38 am (UTC)Binding a secret to PCR state will let you rely on the TPM to do the actual enforcement. If you're just checking PCR values in the TPM and testing a return code, the hardware isn't enforcing, you're just doing a software check - why use a TPM at all?
Good write up. :-)
Kent Yoder
Re: Let the TPM do the enforcement...
Date: 2013-05-08 12:45 am (UTC)Re: Let the TPM do the enforcement...
Date: 2013-05-08 12:55 am (UTC)Re: Let the TPM do the enforcement...
Date: 2013-05-08 01:59 am (UTC)Re: Let the TPM do the enforcement...
Date: 2013-05-08 01:29 pm (UTC)I've been blogging about some of these issues over here: https://www.ibm.com/developerworks/commu
Kent
Re: Let the TPM do the enforcement...
Date: 2013-05-08 02:08 pm (UTC)Re: Let the TPM do the enforcement...
Date: 2013-05-08 02:32 pm (UTC)Kent
Re: Let the TPM do the enforcement...
Date: 2013-08-29 05:27 pm (UTC)1. hp loads win9 + win9mediaPlayer at factory
2. hp configs tpm at factory to only permit connections to www.hollywood.com when consumer is using stock bios, stock bootloader, stock OS, stock DLLs, and stock mediaPlayer.exe (and per another comment by 20xx-or-so all tpm chips will have the EK and presumably 'all' devices will have tpm).
3. jane cannot watch www.hollywood.com movies on her new PC without paying the monthy subscription fee, and cannot record what she does watch unless she pays another fee, and can only watch movies in the fee-category she has signed up for. Software as a service is also fully enforceable: substitute microsoftStreamingAppStoreRuntime.exe for mediaPlayer.exe
4. none of the requirements in #3 are performed by the tpm, they are all part of mediaPlayer.exe, which is really just a shim which downloads the current list of restrictions from the hollywood.com mothership once a week or thereabouts.
Since in this running example mediaPlayer.exe is written to strictly follow those restriction-instructions downloaded from hollywood.com (and verify their SSL key is the real hollywood.com and verify the current timestamp via time.windows.com digisigs), and since the TPM is guaranteeing that no fiddling with the support-layers (bios/boot/os/dll) has happened, it sounds like rock-solid drm to me, barring security flaws in all the complicated parts of this dance, of course. See also, discussion of RestrictedBoot elsewhere on this mjg59 website, for how to keep an untrusted OS out.
I definitely don't understand TPM well enough, however. Be gentle when pointing out the glaringly-obvious-to-you holes in my design. :-)
Re: Let the TPM do the enforcement...
Date: 2013-08-29 05:35 pm (UTC)So you theoretically could construct a site that behaved this way, but not using any current OS. And it would break every time the OS got updated.
Re: state-of-the-art digital restrictions circa 2015
Date: 2013-09-01 05:29 am (UTC)I muddied the waters a bit by talking about Jane and her 'PC', which as you correctly point out, would imply that WindowsUpdate and firmware-flashing (not to mention enduser twiddling of settings in the BIOS like boot-order) would keep interfering with. The better example -- way more likely to happen in 2015+ once the signed EK requirement goes into effect -- is some sort of personal media player device.
Think in terms of iOS and Kindle and even Google Nexus: there is no 'boot order' because there is purposely no expandable storage, there is no way to access the BIOS settings at all, the bootloader is locked down tight as a drum. But go further than them, slightly, and imagine that you are booting into a hypervisor. On top of that, you have two guests: one is an eggshell-thin playback platform, with hardly any actual code inside of it. *This* is the guest that can be verified via TPM and PCR magic, preventing Jane from getting to hollywood.com unless her device is pristine.
The details of how the playback-guest would function are hand-wavy, here, but basically I'm imagining that it would have a network driver and a very simple SSL-aware wget or cURL implementation, which would download the latest *actual* executable from hollywood.com, each and every time you turned on the playback-guest. Any updates to the media player part of the device would generally be server-side ones, that way, which would not require TPM updates at all. The TPM would just verify pristine BIOS, pristine bootloader, pristine hypervisor, pristine media-playback-guest "OS", pristine network driver, pristine cURL, and pristine hollywood.com SSL cert... plus maybe one or two things I forgot. The end.
As for the other hypervisor guest, it would be a general purpose OS, which could be used for email, browsing other websites (not hollywood.com for media-playback of course!), and other non-DRM-protected functionality. None of this area would need to be especially secured, and typical auto-updates could happen over in the general-purpose-guest without screwing up the PCR values stored in the TPM related to the media-playback-guest.
Anyways, methinks that we are going to see devices built along these lines, in less than a decade, once the TPM + EK is more widely deployed, and the hypervisor tech is a bit more mature (presumably Jane will want to watch hollywood.com stuff without 'logging out' of her general purpose OS-guest so there needs to be a cross-guest window manager or somesuch... which prevents the unsecured OS from ever actually seeing the hollywood.com bits ... those go straight from the media-OS-guest to the screen without the generic-OS-guest being able to intercept them).
With luck, by then the average person will know better than to by a device which doesn't come with free-as-in-freedom by default, but that seems more like wishful thinking, as opposed to statistically probable. :-(
p.s. I'm *not* positive it's impossible to make the general purpose guest-OS work in a similar fashion, with just a thin eggshell on the client, which can only connect to os-saas.com for downloading your apps (and only then if you have paid your subscription fees in full for this month....)
TXT
Date: 2013-05-08 05:03 am (UTC)Re: TXT
Date: 2013-05-08 05:26 am (UTC)That I2C bus sounds ripe for interception.
Date: 2013-05-08 07:31 am (UTC)Cutting the bus and inserting your own microcontroller that captures valid updates and replays them sounds like it would be within reach for even a hobbyist, especially in the I2C case.
A successful replay attack would open the door to replacing the boot loader and doing all kinds of mischief...
/greger
Re: That I2C bus sounds ripe for interception.
Date: 2013-05-08 09:05 am (UTC)HOWEVER, PCRs are not "set" to a value. Instead they are "extended" by a value. PCRs get initialized with a set value and when they are extended they do a sha1 of their old and the OS-provided value to calculate the new value... A PCR state thereby contains a hash-chain of all previous "extend" operations. (except for the special cases of resettable PCRs, that can be detected by having a different initial state)
Also authentication is secured "over the i2c/lpc-wire" via challenge-nonce sha1-hmac authentication.
Cheers,
Andreas
Re: That I2C bus sounds ripe for interception.
Date: 2013-05-08 05:25 pm (UTC)https://online.tugraz.at/tug_online/voe_
A hijacker’s guide to communication interfaces of the Trusted Platform Module
http://www.sciencedirect.com/science/art
Re: That I2C bus sounds ripe for interception.
Date: 2013-05-08 08:56 pm (UTC)/greger
AIK PrivacyCA interaction
Date: 2013-05-08 09:14 am (UTC)This gives the same assurance level w.r.t. the "originality" of the TPM and the binding of the AIK to the TPM that the EK originates from. But at the same time it also provides the necessary encryption of the AIK-certificate on its transport from the PrivacyCA to the TPM(-user).
Finally, I'd like to emphasis that there is also the alternative for AIK-activation of Direct Anonymous Attestation (DAA) that can be used alternatively to the PrivacyCA approach. It uses some zero-knowledge-crypto-magic in order to prove that the AIK belongs to an actual TPM but without giving even the (Privacy)CA a possibility to track down users. So you end up not even having to trust them.
(Aside from the one attack, where the CA does not use random numbers (but some internal patterns), but that attack is detectable if you implement appropriate monitoring infrastructure.)
Cheers,
Andreas
Re: AIK PrivacyCA interaction
Date: 2013-05-08 02:10 pm (UTC)Ugh. Yup, that's an obvious mistake. Thanks for the correction!
That's something for me to look into. Thanks!
SSH?
Date: 2013-05-08 12:03 pm (UTC)Re: SSH?
Date: 2013-05-08 01:33 pm (UTC)no subject
Date: 2013-05-08 08:04 pm (UTC)Gave it a whirl on my new new Ivy Bridge Latitude e5430 anyway. Yup, totally useless for normal geeks. What are normal people meant to do with one ?
falken@wopr:~$ tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.37.14
Spec Level: 2
Errata Revision: 2
TPM Vendor ID: ATML
TPM Version: 01010000
Manufacturer Info: 41544d4c
falken@wopr:~$ tpm_getpubek
Tspi_TPM_GetPubEndorsementKey failed: 0x00002004 - layer=tcs, code=0004 (4), Internal software error
falken@wopr:~$
PS You captcha mixes writen out and numeric numbers, but only expects answers in one of them. Must catch people out 50% of the time.
SSL keys
Date: 2013-05-09 02:05 pm (UTC)no subject
Date: 2013-08-20 10:41 am (UTC)At the moment, probably not."
Well, this may not be true currently, MS will be requiring TPM 2.0 from 2015 on all Windows devices with signed EK (page 226 of http://msdn.microsoft.com/en-us/library/w
http://www.zdnet.com/new-bluetooth-audio-t
no subject
Date: 2013-08-20 10:42 am (UTC)"MS will be requiring TPM 2.0 from 2015 on all Windows devices. The TPM will have to have a signed EK."