2

No matter what technique is used to store encryption keys & logins, it seems that all roads lead back to program memory (as far as I know), as an unencrypted version of the keys & logins will be stored there to perform encryption and logging in, and an attacker can physically read from RAM.

Is this true? If so, is there any way to prevent keys & logins from being stored in memory unencrypted?

  • 4
    [HSM](https://en.wikipedia.org/wiki/Hardware_Security_Module)... – Deer Hunter May 29 '13 at 15:45
  • 3
    Additionally, [Homomorphic Encrpytion](http://en.wikipedia.org/wiki/Homomorphic_encryption) might be of some interest to you. – HopelessN00b May 30 '13 at 04:08
  • @HopelessN00b ignoring, of course, the fact that all known systems of Homomorphic Encryption are uselessly impractical right now. – tylerl Jul 16 '13 at 18:27

2 Answers2

7

As DeerHunter points out, pieces of information that should never be accessed by anything other than a hard-wired set of instructions can be stored in a Hardware Security Module.

HSMs hold the key and can perform tasks that use the key, for example generating signatures, without the key ever being known outside the HSM. An HSM is not a box you keep an encryption key in, to be loaded out when it is used - the key stays in the box, the HSM is designed to never egress the key.

However, if your threat model includes attackers that have physical access to RAM, you have no hope. Thats like asking if it is possible to keep thieves out of your house while allowing them into all the rooms.

If all you are aiming to achieve is never having the encryption key present in RAM in its entirety, you could envision an encryption scheme that did not use the entire key at once, perhaps feeding in the key one byte at a time into an iterative algorithm. The result of this iteration would be a block cypher function.

As usual, the bear has provided an excellent answer that covers this topic, and there is no need for me to repeat his efforts.

Community
  • 1
lynks
  • 10,636
  • 5
  • 29
  • 54
  • just to be clear & certain: there is no known technique for keeping unencrypted keys & logins out of memory for a program's use? –  May 29 '13 at 15:51
  • 1
    @Sulla There is, with Hardware Security Modules. The HSM does all the crypto work so that the keys never need to pass through the CPU or RAM. However, if the attacker has physical access to the RAM then he will equally have physical access to the HSM so the point of where the keys are stored and processed is rendered moot. – Iszi May 29 '13 at 15:54
  • 1
    @Sulla not at all. If you were to design an encryption scheme that did not use the entire key at once, perhaps feeding in the key one byte at a time into an iterative algorithm, you could have a situation wherein the key is never stored in memory in its entirety. However, this is not a problem that encryption aims to solve, – lynks May 29 '13 at 15:54
  • @Iszi I suggest that it isn't moot, in that HSMs have significant anti-tamper protection, where CPUs and RAM do not. – Xander May 30 '13 at 23:50
2

If someone you do not want to know your password has direct access to the memory of a computer on which a password is known in plain text, you have failed completely at information security.

At some point, somewhere, your login information simply must exist in plain text. It doesn't have to be there for long, and it should never be persisted to long-term non-volatile memory in this form, but it is simply unfeasible to design a usable system of static credential entry that is invulnerable to "white box" snooping (where the attacker is assumed to have unlimited access to the state information of the machine and can analyse execution step by step). The user must be able to type in his password into a textbox, which stores that password plainly in memory (even if what it shows on screen is a series of bullets), and then your program must be able to retrieve it plainly before encoding it for transport to the authenticating system.

Similarly, something somewhere must know the key you are using to encrypt or decrypt. This, however, doesn't have to be your actual computer. HSMs were suggested; these are data processing modules designed to generate and store keys in a manner that doesn't require direct participation by the CPU or memory of the computer to which it's connected; an ideal black box. They're also designed to resist every effort to get inside this box, from any source including the computer it's connected to. The computer's just a proxy and a source of commands and input data to the HSM. However, that computer must still be trusted, to the extent that during any time an attacker can see and/or control what's being sent between the computer and HSM, he doesn't really need the data in the HSM to compromise your communication or even your key; he has a decryption oracle sitting right there for him to exploit.

If you are worried about keyloggers or other systems that could read a static password, then don't use one; instead, invest in RSA keytags or similar devices. These devices use an algorithm with a starting seed to generate a sequence of numbers, each one valid for one minute or so. The same algorithm, given the same seed value, is generating the same numbers on the server side. Type in the number you see on the tag (waiting for the next one if the current one is about to refresh) as your password. It doesn't really matter if you type that code in on a device that's obviously sending your keystrokes to a guy with a laptop a few feet away; that code will only work for one minute, and thoretically, he has an infinitesimal chance to correctly guess the next code, even if he knew every code that generator has ever produced.

KeithS
  • 6,678
  • 1
  • 22
  • 38