[Cryptech Tech] Roadmap & remarks about the opportunity of developing a secure TOR router on the Novena platform.

[Bernd Paysan]

Am Samstag, 2. August 2014, 18:41:19 schrieb ★ STMAN ★:
> Hello Randy,
> 
> Yes.
> 
> With Linus (TOR Team), we are having two goals :
> 
> - Find a suitable development environment to implement secure TOR routers
> with 100% self made electronics (The closed path to this goal is using FPGA
> (That are NSA backdoored sometimes: The JTAG module can be remotly
> controled with top secret hidden channels)) using FPGA and self design
> processors / peripherals (Ethernet Port, Memory controllers, USB
> Controller, PCIe bus, serial ports, etc..: Let’s say a self made SoC) in
> VHDL : This is the best solution we have to get as much control of the
> hardware as possible, and then port a self-made IP Stack inside this
> environment and also port the TOR daemon routines in this environment : In
> order to reduce the software attack surface, we exclude, for now, using ANY
> KIND OF OS, as long as for such particular application where we just need
> to implement a TCP/IP stack and a few other things, is it not necessary to
> have an embedded OS. Doing so, we are drasticaly reducing the attack
> surface of the whole system : The hardware, and the software attack surface
> too.

If you want to have a drastically smaller attack surface, you also need to go 
drastically simpler.  That probably means not using TOR as it is now (with SSL 
over TCP, both pretty complex protocols of their own), but a protocol where 
you can do the secure routing (mostly) in hardware.

> We will use a new generation of self-made microprocessor architecture that
> is able, by design, to stop ALL THE LOW LEVEL security breach family :
> Stack Overflow, Buffer Overflow (And all their cousins: Integer Overflow),
> but also, the most dangerous low level way of exploiting such low level
> security breach : ROP (Return Oriented Programming). This new processor
> also stops by design all ROP exploits.

IMHO, that stuff is mostly a language problem: The C language has several mis-
features which result in an unified stack, arrays not being first-class (which 
means functions don't know how big a buffer is unless explicitely passed as 
additional, unrelated parameter) and so on.  That's something that can be 
solved:

* The language must pass arrays as addr+len pairs to be able to perform checks 
- the only "pure" pointer without size maybe is the function pointer.

* Parameter stack, return stack and the stack for local buffers must be 
separated (different registers), and the language must have a native way to 
return more than one argument without resorting to pointers (which then opens 
up holes by writing something bigger into the pointer passed).

* The memory overwriting flaws are IMHO the most important to fix.  The 
integer overflow stuff can be partly dealt with in hardware (trap on overflow 
for signed, trap on carry for unsigned), but not completely (sometimes you 
simply want the integers to wrap around and it's perfectly fine).

A high level language like Python can do a good job on the overflow side, but 
a low level language will have difficulites.  And the high level language 
eventually is implemented in the low level language, and some parts of the 
system have to use the low-level parts, so there's no way around having a low-
level language that does at least the most important things right (buffers and 
stacks).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20140802/97d7ac54/attachment.sig>