<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 7, 2016 at 4:18 PM, Harlan Lieberman-Berg <span dir="ltr"><<a>hlieberman@setec.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote><div><br></div><div>This is difficult in the extreme.</div><div>  <br>A missing worry in this discussion is processor design.   Speculative </div><div>execution can cause code paths to exist ignoring asm binary bits but have</div><div>output apparently abandoned based on another branch.  Some</div><div>side effects might get to memory or be present in cache. <br><br>Some telemetry and inspection of the code is justified.  Debuggers </div><div>might help keep secrets secret because in looking with a debuggers the CPU and </div><div>instruction flow are touched.  Debugger recursion was unreliable or </div><div>impossible in the past so it might be more secure to run under a debugger ;-?</div><div><br></div><div>The operating system's management of memory objects is important.<br>The design and implementation need to be reviewed.<br><br>Common object reuse policy of some OSs can defer bzero(or-randomization) of the memory </div><div>to later as long is it is not given to another process without clearing. <br>That clearing might be tomorrow or next month and sleep resume cycles </div><div>can put data into non-volatile storage near or far as can a core dump (crash).<br>If a debuggers can be attached almost all bets are off.  The system call to fork()</div><div>and IPC shared memory communications are a tangle.  </div><div><br>Possibly good news is hard to guess generated "random" bits are still possible.   </div><div>I suspect that important keys  and secrets in code could be more secure with </div><div>the use of one or more generated one time buffer pads.   Thus access to the </div><div>important secret would need an XOR step against the buffer with a buffer</div><div>pad unique to a run. <br><br></div><div>This puts an additional hard to guess ephemeral secret between the important</div><div>bits and a scavenger attempting to discover hints in swap space </div><div>or a kernel resident inserted thread attempting to glean hints from what</div><div>should be a clean system memory space would have a more difficult</div><div>task.  i.e. strings would not find strings because the string buffer would</div><div>be obfuscated.   Tests that look for numbers or strings involving important</div><div>keys would have to first discover the ephemeral secrets (OTB, one time buffers).  <br><br>This all reflects how difficult it is to secure a system without physical security.<br>For some systems pulling the power is sufficient but as fast as flash storage</div><div>is who knows what work can take place inside a 60Hz cycle.<br><br>Multi core systems (SMP) can see all memory so if the kernel can be</div><div>hacked another core can walk the TLB and memory map tables and<br>grab anything except register contents directly.  A context switch spills</div><div>registers so they can be seen.<br><br>Graphics subsystems?</div><div><br></div><div>I still have some MC68000 parts..  if I had any important secrets to keep I might</div><div>dust off some old designs or go rummaging in WierdStuff.  </div><div><br></div><div>An interpreted language or system even C on a home crafted virtual machine</div><div>might give more control.</div><div><br></div><div><br><br><br><br></div></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>