On Thu, Sep 21, 2017 at 11:16 AM, Philip Hands phil@hands.com wrote:
Most of the time, what you're calling hardware is liable to just be software running on a different processor, perhaps in a box that has been glued shut such that it's less convenient for bugs to be found, fixed and patched.
glued shut, electric fences added which electrocute the user, or run the instruction "HCF" [Halt and Catch Fire. mythical iinstruction which was supposed to be in the 68000 or perhaps the 8086, but was actually down to running a loop of instructions that flipped IO and internal logic so hard that the processor overheated). :)
the latest freescale has an on-board Cortex M0 i think it is, which is ultra-low-power enough to run permanently on battery, so you can do tamper-detection.
you'll like this: when i was working for NC3A i was asked to help with a little ethernet network box that transferred data from a low-security environment to a high-security one. the rule was simple: absolutely no physical connection, and absolutely no data must travel - ever from the high security level to the low security one.
that *includes* ICMP packet responses which are normally used to acknowledge and set up even a *UDP* connection.
so somebody wrote a *modified* TCP stack which took out the need for ICMP traffic... but it went way waaay further than that.
the metal box was implemented as an ultra-low power receiver / transmitter pair, with a metal firebreak and a tiny hole between for the radio signal to get through on a Coax cable (so that there was no data leakage by emitted radio waves).
power was SEPARATELY provided on both sides of the box.
then.... when it was confirmed 100% working, the ENTIRE BOX WAS FLOODED WITH RESIN.
bit of a heat problem, that....
baiscally what i'm saying, with this story is: the tricky part will not be the software at all: the tricky bit will be getting a processor into a tamper-resistant, tamper-detecting box.
l.