19

Maybe I'm essentially asking an electronics / storage question...

This question is similar, though I think it was maybe asked more about physical security while the answer was more about malware.

This question explains that YK "stores the key on its internal storage media".

An article on YK's site says "In Yubico’s case, the PIN resides on the YubiKey"

I'm not overly worried about people stealing my device with no chance to revoke things, but theoretically, I just don't understand what makes it complicated to read the 8-byte PIN.

Given that Yubico has this article on a complicated side channel attack, it would seem the storage is not easy at all to access.

Where would this data live on the device if not on something like flash storage? I am used to thinking about "files" on a device, but I guess there are no files?

dcc310
  • 301
  • 2
  • 5
  • 5
    Note that a PIN isn't necessarily stored in plaintext at all. Often, one encrypts the secrets one needs with a value derived from your PIN, and then given a candidate PIN, tries to decrypt contents with it; if one gets a private key that matches up with the public key, then one knows the PIN was correct; but using a complicated derivation function can slow down the rate of guesses, and if that derivation function is only available behind hardware that decrements a counter before use (and increments it again on success), one can implement things like "wipe the key after N incorrect guesses". – Charles Duffy Mar 08 '21 at 00:11
  • 4
    (Note the "decrement the self-destruct counter before use, increment again after if the PIN was shown to be valid", _not_ "decrement after an invalid PIN was detected" -- the latter can be bypassed with voltage glitching attacks that see when the chip is trying to pull enough power to update its values in flash, and then cut off the power before the write goes through). – Charles Duffy Mar 08 '21 at 00:11
  • @CharlesDuffy, those are useful patterns to remember. Similar to that, from [here](https://developers.yubico.com/yubikey-piv-manager/PIN_and_Management_Key.html) (see "Management Key" and PBKDF2 part), it seems like they can make a key from your PIN if you don't provide a key. Their CLI help also says they can make you "a random key" that's "protected by PIN". Plus they say the "PIN resides on the Yubikey". Maybe in some contexts it's helping to generate a key, and in others, it's just an N-try password? Maybe just some inconsistent wording in one of the three docs... – dcc310 Mar 08 '21 at 04:09
  • Do "rubber hose decryption" or other forms of social engineering to convince the person to tell you their key count? – nick012000 Mar 08 '21 at 04:45
  • 2
    @nick012000, how is the owner of a yubikey expected to know the private key it contains, no matter how much duress they're under? The PIN, they know. The private key, not so much. – Charles Duffy Mar 08 '21 at 05:21
  • @CharlesDuffy I'm not familiar with the particulars of this particular encryption scheme, but if there's a number or password that the user would know that the attacker can put into the computer to decrypt things, that would be a form of key. – nick012000 Mar 08 '21 at 05:45
  • 4
    @nick012000, ...the distinction between a key and a PIN is important here. The _key_ can decrypt or sign things at any time, on any general-purpose CPU capable of doing the relevant math (or a very, very patient human with a lot of paper and time); the _PIN_ can only be used to decrypt or sign things in presence of the physical device holding the key -- hence a question about how hard it is to steal the key off the device being important to folks trying to evaluate security posture. – Charles Duffy Mar 08 '21 at 17:44
  • 3
    @nick012000, ...that said, anyone trying to do rubber-hose cryptanalysis would just steal the device _and_ persuade their target to give up the PIN, putting it well out-of-scope for any relevant design/analysis. It's more evil-maid situations (where an adversary has temporary hardware access unknown to their target) where this is a relevant question; applying rubber-hose techniques violates the "unknown to their target" constraint. – Charles Duffy Mar 08 '21 at 17:49

1 Answers1

52

Short answer

Where would this data live on the device if not on something like flash storage?

It probably is flash, but it's put in a chip that's hard to take apart and examine without destroying the data you're trying to read. It's not impossible to do, but it's really quite difficult and expensive. It's not like a hard drive or flash drive where you can just remove it and plug it into a new computer.


Long answer

It is stored on a tamper-resistant solid-state chip. Most likely it is flash, but is designed in such a way that it's difficult to non-destructively remove the IC cover to expose the actual die (a process known as decapping). There are many ways to achieve this, but they can all be bypassed with enough effort. You should assume that anyone with a sufficiently-equipped laboratory will be able to break into it.

The usual way to read data from a poorly-protected IC (such as an 8051 chip with the firmware read-protect bit set) is to decap it with acid and then take a detailed photograph of the die. This makes it possible to reverse engineer the design and find the relevant components that will be storing the data you want. If you know where the data is stored, you can simply read the bits off it by examining the electrical properties of those components. A protected IC (like a TPM or Yubikey) merely attempts to make this more difficult. Many barriers are put in place to slow this down, to obfuscate the location of the secret data, and to increase the chances that the die will be damaged during decapping.

For example, see this discussion on forensic recovery from microcontrollers. It has this to say:

Decapsulating the YK4 and sticking it under an optical microscope reveals, well, not a whole lot. Pretty much every active part of the die apart from the bond pads is shielded by a metal layer that prevents the kind of visual inspection and simple UV tampering I described earlier.

One would have to de-process the device further using more exotic (and dangerous) acids or by wet lapping to reveal the true structure hidden underneath. These are destructive processes that render the circuit non-functional.

That’s not to say these types of defenses can’t be bypassed, but getting around such protections usually requires significant investment. Other types of mitigations focus on the detection of decapsulation by placing light sensors on the die itself to detect when the chips powers up after the molding compound has been removed. SIM cards often include an active mesh layer that can detect when a single trace has been cut.

Another technique to retrieve data is to use glitching attacks, which are made possible when the voltage or clock are controlled externally. If the voltage or clock are varied, it can induce glitches that may result in side-channels that expose secrets from the otherwise "sealed" integrated circuit. A well-designed secure storage system will make this nearly impossible, but new attacks are discovered from time to time. You can never completely rule glitching attacks out, but they may not be easy. If someone is going to decap the chip and expose the die and run it while beaming lasers at individual transistors and traces for fault injection attacks, there's not much they won't be able to recover.

Regular passive side-channel attacks (monitoring power usage, heat, sound, or radiation during processing of sensitive material) are easier to protect against. This can be done by using constant-time operations which take the same amount of time regardless of the data being processed, or with masking, which ensures that an operation takes the same amount of electrical power regardless of what is being processed. This is very effective and protecting against passive attacks, but glitching attacks as described above may force the system into an undefined state that violates the security guarantees provided by constant-time operations and masking, and could reveal secret data.

forest
  • 64,616
  • 20
  • 206
  • 257
  • I wonder how they would react to thermite and phosphorous under the cap. – Joshua Mar 09 '21 at 00:00
  • @Joshua That would destroy the data that the OP is trying to recover, so that approach is pretty counterproductive. – HiddenWindshield Mar 09 '21 at 04:16
  • 3
    @HiddenWindshield: I am imagining designing the secure chip, not breaking into it. – Joshua Mar 09 '21 at 04:18
  • 2
    @Joshua If you're referring to a self-destructing chip, that kind of thing has been done before. It's generally only effective if the attacker does not have many copies to analyze, so it's really only useful to military technology where a limited number are produced. For a mass-produced smart card, it would not pose a particularly high barrier (self-destruction, that is). Furthermore, it would be better to chemically destroy it than to try to burn it up (not to mention, thermite has such a high ignition temperature that you couldn't fit the detonator in such a little, low-power device). – forest Mar 09 '21 at 05:37
  • 7
    One of the principal security benefits of including *something you have* in an authentication scheme is that at any given time you know unambiguously whether you've got it. If you haven't, it means someone else has, at which point you contact your security people and they revoke that particular device, preferably doing all this in a timescale that's short compared to the time required to extract usable secrets from the device. – MadHatter Mar 09 '21 at 07:53
  • @forest: Prosperous ignites on contact with air. – Joshua Mar 09 '21 at 16:22
  • @Joshua: The reason it only works once is that once you know how it works, you can work around it. I admit to being unsure how to work around phosphorus, but I'm equally unsure how to implant phosphorus in a chip. Also, my gut feeling is that putting phosphorus in a device that will sit in someone's pocket is a bad idea; it will be shaken around, experience varying temperatures, and otherwise have various experiences that should perhaps not happen to a highly reactive compound. – Brian Mar 09 '21 at 18:09
  • 3
    If I was asked for an idea to engineer this, I'd reckon on a conventional epoxy outer shell and then alternating layers of *porous* PTFE, gold, silicon, titanium, etc. A different solvent/reagent would be needed for each, and as each solvent was used, it would diffuse through the pores and attack the actual chip's substrate and metallisatiion. But that would still be prone to the use of something like a diamond microplane to remove the layers mechanically in an inert atmosphere. – Rich Mar 09 '21 at 21:49
  • 2
    All these techniques people are suggesting are things that may work to some extent, but once an attacker has destroyed enough chips in their experiments, they'll be able to reliably decap it without damaging the data inside. There are some ICs which are designed to be _extremely_ difficult to decap. The Yubikey is much easier to attack than some other highly security-oriented chips (which is why it is inexpensive), but it is not _easy_ to get into like a good old fashioned Atmel 8051. – forest Mar 09 '21 at 23:26