A Password Is Not Enough : Crypto Attack Vectors

  • 8 March 2014
  • 0 replies
  • 2 views

Userlevel 7
Badge +52
I break attacks into three fundamental tiers. First off, non-invasive, which is something that you might be able to execute with just a flash drive; you don’t even need to take the system apart, where you could attach to it some other hardware component, like a PCI card, ExpressCard, or Thunderbolt (the new adapter that gives you basically naked access to the PCI bus). Secondly, we’ll consider attacks where screwdriver might be required, where you might need to remove some system component temporarily to deal with it in your own little environment. And also, soldering iron attacks, which is the most complicated, where you are physically either adding or modifying system components like chips on the system in order to try to break these things.
 
RAM is not terribly trustworthy from the security perspective.So, wouldn’t it be nice if we could keep our key somewhere else in RAM? Because we’ve sort of demonstrated that RAM is not terribly trustworthy from the security perspective. Is there any dedicated key storage or cryptographic hardware? There is. You can find things like cryptographic accelerators and use them in web server so you can handle more SSL transactions per second. They are tamper resistant, or certificate authorities have these things that hold their top secret keys, but they are not really designed for high-throughput operations like using disk encryption. So, are there any other options?
Can we use the CPU as sort of a pseudo hardware crypto module? Can we compute something like AES in the CPU using only something like CPU registers? Intel and AMD added these rather excellent new CPU instructions which actually take all the hard work of doing AES out of your hands; you can just do the block cipher primitive operations with a single assembly instruction. The question is then: can we store our key in memory and can we actually perform this process without relying on main memory? We have a fairly large register set on x86 processors, and if any of you have actually tried adding up all the bits that you have in registers – it’s something like 4 KB on modern CPUs. So, some of it we can actually dedicate to key storage and scratch base for our encryption operation.
 
One possibility is using the hardware breakpoint debugging registers. There are four of these in your typical Intel CPU, and in x64 these are each going to hold 64-bit pointer. That’s 256 bits of potential storage space that most people will never actually use. The advantage, of course, to using debug registers is: one – they are privileged registers, so only the operating system can access them; and you get other nice benefits, like when the CPU is powered down either by shutting off the system or putting in sleep mode you actually lose all register contents, so you can’t cold-boot these. A guy in Germany, Tilo Muller, actually implemented this thing as TRESOR for Linux in 2011, and he did performance testing on it and it’s actually not any slower than doing your regular AES computation in software.
 
How about, instead of storing a single key, we can store 128-bit keys?
This gets us into more of the crypto module space. We can store a single master key which never leaves the CPU on boot-up, and then load and unload wrapped versions of keys as we need them for additional task operations.
The problem is, we can have our code or our keys stored outside of main memory, but the CPU is ultimately still going to be executing the contents of memory. So, with DMA transfer or some other manipulation you could still alter the operating system and get it to dump out the registers in main memory, or if they are somewhere more exotic, like debug registers.
Full Article
 
 
 
 
 

0 replies

Be the first to reply!

Reply