[Cryptography] Understanding state can be important.

[Arnold Reinhold]

> On Dec 30, 2015, at 9:10 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
> 
> At 01:31 PM 12/29/2015, Arnold Reinhold wrote:
>> My solution to the write-protect problem involves two single purpose devices.
>> 
>> One is a board that would serve as a write-protect shield for an SD card.
>> 
>> All SDcards implement a Serial Peripheral Interface Bus (SPI), which is supported on the Arduino and R Pi platforms.
>> 
>> The SDcard specs, e.g. http://blog.chinaaet.com/282280072/p/17750, include a set of commands.
>> 
>> There are two for writing blocks: CMD24 and CMD 25.
>> 
>> The wedge board would send commands and data to and from the SDcard transparently except that it would block the Write commands.
>> 
>> This feature might be controlled by a switch or a jumper on the board.
>> 
>> A light or sound alert could warn of a write attempt.
>> 
>> The write-protect board with an SDcard installed might be made to act like a USB flash drive.
>> 
>> This should be easy to do on a Raspberry Pi Zero ($5 retail), using the Pi Zero's USB port.
> 
> I'd be happy with a *true* "USB condom"; one that MITM'd the USB port and made damn sure that a passive memory device acted like a *single* *passive* memory device, and not a keyboard/mouse/whatever; it would also watch out for any changes in its VID/PID.
> 
> This same device could also ground any write commands.
> 
> I've seen some cheap devices that could conceivably do this, but the manufacturer would have to allow me reprogram the firmware.
> 

What devices have you looked at? There are several out that have no firmware that should be up to the task, e.g. the Beagle Bone or the Teensy 3.2. It’s  just a matter of programming.  What am I missing?

Henry also wrote:

> One significant problem with malware is that it can *delete log files*, so that finding out what it was up to can be difficult.
> 
> Soooo, you need a *write-once*, *append-only* device to act as a logger.
> 
> It's sad, in this day and age, that the best logger may be an old-style continuous paper printer.
> 
> It's hard to imagine malware that's capable of reaching out & shredding that "log file".
> 
> This is why traditional (paper-based) *accounting systems* are append-only.  You can never erase an entry; you can only add a correcting entry, so that it can later be audited.  Financial systems & auditors have had to deal with bad people trying to "hack the books" for centuries.
> 
> The Bitcoin blockchain is an analogous system that would require overwhelming force (i.e., some plurality of the computing power) to change an entry.
> 
> Unfortunately, it's not that simple w.r.t. malware & logs.
> 
> The malware can force the log files to be encrypted with a key of their choosing -- sort of like ransomware -- so the resulting log files may exist, but will be gibberish.
> 
> Perhaps Mr. Comey has a solution for this problem?

This seems like a perfect application for a small machines like the Raspberry Pi. Build minimalist distro that listens for log packets on Ethernet, or a USB port, say, and writes them to the Pi’s SDcard (with the distro on it). When the card is close to full, the Pi could signal an alarm via a GPIO pin to request a new pre-configured SDcard. Meanwhile it could keep overflow log messages in its RAM. Modifying server OS’s to send copies of all log messages to the Pi should should be easy enough. Of course once the malware takes over, log messages will disappear or be phony, but there is no way to prevent that. The Pi software would have to be hardened to prevent malware-generated log messages from infecting the Pi or modifying what was already recorded. That doesn’t seem insurmountable. The Pi software could also allow network read-only access to the log files, maybe depending on a jumper on the Pi board. 

This seems like a most worthy open source project. Once such a logging distro is available, hooking up a $5 Pi Zero, say, to any security sensitive server to save log files should be cheap and easy. 

Peter Gutmann wrote 

> >The Texas Instruments 430 processor line has some FRAM versions available;
> 
> The downside is that you then have to work with an MSP 430, one of the world's
> truly awful CPUs.  You're better off tacking a FRAM on the side of something
> sane.

Agreed. Anyway, there are many microprocessors that include a few K of on board eeprom. The goal I thought was to have portable memory that is also selectively erasable. And inexpensive FRAM modules are available to today retail.

> 
> Why would you want FRAM though?  You still need to erase it to prevent
> capture, and its remanence properties are largely unknown.

The need to erase is obviously an issue with any memory. The remanence properties of flash drives are known to be horrible as several posts have pointed out.  One alternative is to use SRAM with a small backup battery that can be removed, but my understanding is that this would not be a reliable erasure. FRAM is small, fast and allows large numbers of writes, so overwriting each byte randomly many times should not take long. The number of passes could be conservative enough (32?) to make recovery unlikely.

Happy 2016,

Arnold Reinhold