[Cryptography] Secure erasure in C.

Tom Mitchell mitch at niftyegg.com
Fri Sep 9 14:12:41 EDT 2016


On Wed, Sep 7, 2016 at 4:18 PM, Harlan Lieberman-Berg <hlieberman at setec.io>
wrote:

> If you really want to be sure it's dead and buried, what about doing the
> erasure with inline asm? I know GCC, at least, has a keyword to tell it not
> to mess with a particular assembly block.


This is difficult in the extreme.

A missing worry in this discussion is processor design.   Speculative
execution can cause code paths to exist ignoring asm binary bits but have
output apparently abandoned based on another branch.  Some
side effects might get to memory or be present in cache.

Some telemetry and inspection of the code is justified.  Debuggers
might help keep secrets secret because in looking with a debuggers the CPU
and
instruction flow are touched.  Debugger recursion was unreliable or
impossible in the past so it might be more secure to run under a debugger
;-?

The operating system's management of memory objects is important.
The design and implementation need to be reviewed.

Common object reuse policy of some OSs can defer bzero(or-randomization) of
the memory
to later as long is it is not given to another process without clearing.
That clearing might be tomorrow or next month and sleep resume cycles
can put data into non-volatile storage near or far as can a core dump
(crash).
If a debuggers can be attached almost all bets are off.  The system call to
fork()
and IPC shared memory communications are a tangle.

Possibly good news is hard to guess generated "random" bits are still
possible.
I suspect that important keys  and secrets in code could be more secure
with
the use of one or more generated one time buffer pads.   Thus access to the
important secret would need an XOR step against the buffer with a buffer
pad unique to a run.

This puts an additional hard to guess ephemeral secret between the important
bits and a scavenger attempting to discover hints in swap space
or a kernel resident inserted thread attempting to glean hints from what
should be a clean system memory space would have a more difficult
task.  i.e. strings would not find strings because the string buffer would
be obfuscated.   Tests that look for numbers or strings involving important
keys would have to first discover the ephemeral secrets (OTB, one time
buffers).

This all reflects how difficult it is to secure a system without physical
security.
For some systems pulling the power is sufficient but as fast as flash
storage
is who knows what work can take place inside a 60Hz cycle.

Multi core systems (SMP) can see all memory so if the kernel can be
hacked another core can walk the TLB and memory map tables and
grab anything except register contents directly.  A context switch spills
registers so they can be seen.

Graphics subsystems?

I still have some MC68000 parts..  if I had any important secrets to keep I
might
dust off some old designs or go rummaging in WierdStuff.

An interpreted language or system even C on a home crafted virtual machine
might give more control.








-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160909/ad7529d9/attachment.html>


More information about the cryptography mailing list