Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zeroing buffers is insufficient

daemonology.net

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Zeroing buffers is insufficient

#71

Post by tedunangst »

delinka wrote: post #17

Why are there no suggestions to change processors accordingly? Intel should be considering changing the behavior of its encryption instructions to clear state when an operation is complete or at the request of software. Come to think of it, every CPU designer should be considering an instruction to clear the specified state (register set A, register set B) when requested by software. Then, the compiler can effectivel…

You can clear the CPU state. But how is the CPU to know when it's safe to clear unless the software tells it?

Re: Zeroing buffers is insufficient

#72

Post by geertj »

AlyssaRowan wrote: post #2

It's becoming gradually more tempting to write a crypto library in assembly language, because at least then, it says exactly what it's doing. Alas, microcode, and unreadability, and the difficulty of going from a provably correct kind of implementation all the way down to bare metal by hand. The proposed compiler extension, however, makes sense to me. Let's get it added to LLVM & GCC?

This is what djb is doing using his "qhasm" assembly like language. He seems to be doing it for performance though, not to work around too aggressive compilers.

As an alternative, maybe write crypto algorithms in LLVM IR?

Re: Zeroing buffers is insufficient

#73

Post by Symmetry »

xorcist wrote: post #60
Symmetry wrote: post #24

Earlier quoted context omitted.

Last I heard they're still limited to sims and are concentrating on patent filings. The bootstrap strategy is LLVM (once they get around LLVM assuming addresses are integers as opposed to the Mill's compound things) and to get Linux running on top of L4 which seems doable[1]. They say they're looking for a niche to start in before going after PCs. [1] http://l4linux.org/

Why on L4? Is Mill somehow tied to it, architecture-wise? Or is it just that L4 has a smaller footprint and is easier to port?

Because the Mill has a single address space with memory protection, which works a lot better with L4 than it does with Linux. Porting Linux directly would probably be possible, but a huge effort the team wouldn't be able to pull off without a lot of extra resources.

Re: Zeroing buffers is insufficient

#75

Post by Symmetry »

AlyssaRowan wrote: post #33
ctz wrote: post #4

Earlier quoted context omitted.

That works for well-defined ISAs (like ARM), but not for those with undocumented pipelines, or instructions defined by practise (like x86 and amd64). In other words, if you write a crypto library in x86 assembler, Intel don't guarantee that they won't introduce a side channel in their next chip model or stepping.

Sadly, I know that only too well: hence my "alas, microcode" comment! A prefix or mode or something which allows code to handle secure data and it gets constant-time multipliers, for example, or true µop-level register zeroisation, would be handy, but also close to unverifiable - we just have to sort of trust it, which sucks. Until then, we do the best we can with turtles all the way down. Software running under that…

There's a fundamental difference between your main memory and your L3 in that the former is DRAM and the later is SRAM. In DRAM you have a charge hidden in a well behind a single transistor and it's designed to be stable for a while (the refresh interval) without anybody doing anything to it. SRAM doesn't have that static component at all, it's a set of 6 or 8 transistors which have two stable configurations when powered and which lose their state as fast as all the other logic in your chip as soon as the power is cut.

You can play with the temperature if you want, but the mechanisms that prevent unauthorized access in normal conditions will have their lifetimes extended or decreased as much as you change the lifetime of the data you're trying to access. And liquid nitrogen temperatures at least tend to make everything happen faster in CMOS circuitry. That's governed by a complex interaction between the effect of temperature on carrier density and carrier mobility, so I'm not sure that you couldn't slow things down with, say, liquid helium, but even then I'm not sure you're buying anything.

Re: Zeroing buffers is insufficient

#76

Post by willvarfar »

xorcist wrote: post #60
Symmetry wrote: post #24

Earlier quoted context omitted.

Last I heard they're still limited to sims and are concentrating on patent filings. The bootstrap strategy is LLVM (once they get around LLVM assuming addresses are integers as opposed to the Mill's compound things) and to get Linux running on top of L4 which seems doable[1]. They say they're looking for a niche to start in before going after PCs. [1] http://l4linux.org/

Why on L4? Is Mill somehow tied to it, architecture-wise? Or is it just that L4 has a smaller footprint and is easier to port?

Its about footprint. We certainly will run Linux on the Mill, but its work we don't have to put on the critical path. L4 is just a familiar lightweight OS, and we're keen to play with Mill-specific security features which are particularly applicable to microkernels too.

When we do port Linux, I expect it to become much more microkernel like, as in why would you want your disk drivers to be able to read write video memory etc?

Re: Zeroing buffers is insufficient

#77

Post by cperciva »

pbsd wrote: post #61

> For encryption operations these aren't catastrophic things to leak — the final block of output is ciphertext, and the final AES round key, while theoretically dangerous, is not enough on its own to permit an attack on AES This is incorrect. The AES key schedule is bijective, which makes recovering the last round key as dangerous as recovering the first.

Oops, quite right. I was looking at the "mix and xor" and my brain jumped to "oh, this is the standard hash idiom" and I completely missed the fact that the word being xored is not the word being mixed...

Re: Zeroing buffers is insufficient

#78

Post by tedunangst »

AlyssaRowan wrote: post #43
pinkyand wrote: post #21

Earlier quoted context omitted.

Assembly is bad for auditability, which is important in crypto to prevent subtle errors.

As a seasoned and experienced reverse-engineer myself, I'm (genuinely) curious where you got that impression. Do you find it unapproachable? Assembly is the simplest language you can write a computer program in, for a certain very textbook definition of "simple" - it's just that you actually have to do everything by hand that you normally wouldn't. And yes, that can be a pain in the ass, and yes, you do have to watch…

The briar patch of OpenSSL is more in the high level protocol code, and not the asm crypto (the perl obfuscation layer makes it fun, but isn't a major source of bugs). I would not want to write a robust asn.1 parser in assembly. Lots of other cruft works around the presence or absence of various #define values in header files. Rewriting in assembly is not going to solve the problem of deciding how big socklen_t is.

Re: Zeroing buffers is insufficient

#79

Post by cperciva »

cheez wrote: post #16

The suggestion has the right idea, but the wrong implementation. The developer should be able to mark certain data as "secure" so the security of the data travels along the type system. Botan, for example, has something called a "SecureVector" which I have never actually verified as being secure, but it's the same idea.

This was my initial idea, but talking to compiler developers convinced me that the dataflow analysis needed for this would be tricky. They were much happier with the idea of a block-scope annotation.

Re: Zeroing buffers is insufficient

#80

Post by tedunangst »

rsync wrote: post #74

Would running your file system read only and optimizing the system for fast bootup be a workaround ? If so you could zero successfully by rebooting...

After what? Every https request? Simply exiting the process is sufficient to prevent most info leaks, but even that's much too slow and not even a solution. The class of bugs here is that sensitive data is in memory and then the same program inadvertently leaks it while performing some other operation. If you reboot before the leak, you won't make it to that other operation, sure, but your program won't be much use either.

User logs in by sending password. System transitions to authorized state. System wants to wipe password to avoid later leak. If you reboot at this point, the user will no longer be authorized.

Post reply on HN