Difference between revisions of "OHSNAP"
Line 18: | Line 18: | ||
<h2>Status</h2> | <h2>Status</h2> | ||
+ | <h3>April 3, 2021</h3> | ||
+ | <p>Identified three regimes for threat models, some concrete examples, and some hypothetical mitigations:</p> | ||
+ | <table style="border: 1px solid black; " cellspacing="3" bgcolor="#000000"> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <th style="padding: 1em;">Threat Regime</th> | ||
+ | <th style="padding: 1em;">Example Scenario</th> | ||
+ | <th style="padding: 1em;">Possible Mitigations</th> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td style="padding: 1em;">During assembly</td> | ||
+ | <td style="padding: 1em;">Manufacturer tampering</td> | ||
+ | <td rowspan="3" style="padding: 1em;"> | ||
+ | <ul> | ||
+ | <li>PCB x-ray inspection</li> | ||
+ | <li>[https://cercuits.com/transparent-pcb/ Translucent PCB substrate] for visual inspection</li> | ||
+ | <li>Encase PCB in glitter epoxy</li> | ||
+ | <li>[https://www.mcmaster.com/tamper-evident-markers Tamper-evident paint] | ||
+ | <li>Apply heat-sensitive paint to PCB (detects soldering)</li> | ||
+ | <li>Vacuum-sealed enclosure with onetime-use pressure sensor</li> | ||
+ | <li>Serial numbers in ROM on ICs</li> | ||
+ | <li>Use common enough chip to reduce chance of silicon tampering</li> | ||
+ | <li>Pogo board testing</li> | ||
+ | </ul> | ||
+ | </td> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td rowspan="3" style="padding: 1em;">During transit to end-user</td> | ||
+ | <td style="padding: 1em;">Vendor/reseller tampering</td> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td rowspan="2" style="padding: 1em;">Mail interdiction</td> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td style="padding: 1em;">Embed device in another device</td> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td rowspan="3" style="padding: 1em;">At customer's install site</td> | ||
+ | <td rowspan="2" style="padding: 1em;">Evil user tampering</td> | ||
+ | <td style="padding: 1em;">Live system intrusion detection (examples??)</td> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td style="padding: 1em;">Routine pogo board testing</td> | ||
+ | </tr> | ||
+ | <tr bgcolor="#ffffff"> | ||
+ | <td style="padding: 1em;">Passive monitoring, e.g., | ||
+ | <ul> | ||
+ | <li>audio/video monitoring of keypresses</li> | ||
+ | <li>RF leakage analysis</li> | ||
+ | <li>power analysis</li> | ||
+ | </ul> | ||
+ | </td> | ||
+ | <td style="padding: 1em;">???</td> | ||
+ | </tr> | ||
+ | </table> | ||
+ | |||
<h3>March 27, 2021</h3> | <h3>March 27, 2021</h3> | ||
<p>Still looking for a non-BGA ARM processor that contains two Ethernet PHYs and has 0.5mm or greater lead pitch (for [https://www.voltera.io Voltera V-1] PCB production. We are now considering three options for design:</p> | <p>Still looking for a non-BGA ARM processor that contains two Ethernet PHYs and has 0.5mm or greater lead pitch (for [https://www.voltera.io Voltera V-1] PCB production. We are now considering three options for design:</p> | ||
Line 84: | Line 139: | ||
* '''Related projects''' | * '''Related projects''' | ||
** [https://www.kosagi.com/w/index.php?title=Novena_Main_Page Kosagi Novena] - bunnie Huang's open hardware ARM SBC with OpenBSD support and dual Ethernet | ** [https://www.kosagi.com/w/index.php?title=Novena_Main_Page Kosagi Novena] - bunnie Huang's open hardware ARM SBC with OpenBSD support and dual Ethernet | ||
+ | ** [https://opencircuits.com/index.php?title=Linuxstamp Linuxstamp] – open source non-BGA ARM9 Linux-capable SBC with 10/100 Ethernet on a 2-layer board | ||
+ | ** [https://ethernetfmc.com EthernetFMC] - open hardware GigE transceiver with RGMII interface based on [https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e151x-datasheet.pdf Marvell 88E1510 chip] | ||
** Deprecated projects | ** Deprecated projects | ||
*** [http://securityrouter.org/wiki/Main_Page SecurityRouter] - OpenBSD distro for network management | *** [http://securityrouter.org/wiki/Main_Page SecurityRouter] - OpenBSD distro for network management | ||
Line 103: | Line 160: | ||
** [https://www.sfcircuits.com San Francisco Circuits] | ** [https://www.sfcircuits.com San Francisco Circuits] | ||
** [https://www.circuitlaunch.com CircuitLaunch] | ** [https://www.circuitlaunch.com CircuitLaunch] | ||
+ | ** [https://oshpark.com OSHPark] | ||
* '''Design tools''' | * '''Design tools''' | ||
** [https://kicad.org KiCAD] - schematic capture and PCB layout | ** [https://kicad.org KiCAD] - schematic capture and PCB layout | ||
+ | * '''Anti-tampering''' | ||
+ | ** [https://cercuits.com/transparent-pcb/ Transparent PCB] manufacturer | ||
+ | ** [https://www.mcmaster.com/tamper-evident-markers Tamper evident markers] | ||
+ | ** Wikipedia article on [https://en.wikipedia.org/wiki/Tamper-evident_technology Tamper Evident Technology] | ||
+ | ** [https://media.ccc.de/v/36c3-10690-open_source_is_insufficient_to_solve_trust_problems_in_hardware#t=2848 "Open Source is insufficient to solve trust problems in hardware"] by Bunnie Huang (video presentation) |
Revision as of 19:56, 10 April 2021
Open Hardware for Secure Networks And Privacy (OHSNAP)
This is the project page for OHSNAP, an open-source platform for building secure networks with a known root of trust.
Motivation
Virtually all commercially-available networking equipment is proprietary and closed-source and cannot be independently verified to be free of malware. There have been documented cases of attackers – sometimes entire nation-states – physically modifying networking equipment and networkable devices in order to exfiltrate data and/or command & control otherwise-trusted systems. This leaves the average individual with little choice but to hope that their home network consists of and is secured by devices which do not phone home or contain other backdoors. Such a situation breaks the guarantee that the user's data and devices remain their sovereign property and instead places control into the hands of manufacturers and governments.
The goal of this project is to produce a completely open design and implementation for a network router with a verifiable root of trust. By making the hardware design, manufacturing process, and firmware and software stacks fully verifiable, it allows users to inspect the entire end-to-end flow of their data and to directly control some or all of the fabrication of the device in order to establish positive provenance.
Device Summary
The OHSNAP router will be a single-board computer running an open source firmware and OS. It will expose at least two Ethernet ports.
Design Goals
- No closed-source firmware or software allowed anywhere in the stack
- Implementation must be independently reproducible by third parties
- Factory-made PCBs must be physically produced in the USA
- Components should be as supplier-diversified as possible
Status
April 3, 2021
Identified three regimes for threat models, some concrete examples, and some hypothetical mitigations:
Threat Regime | Example Scenario | Possible Mitigations |
---|---|---|
During assembly | Manufacturer tampering |
|
During transit to end-user | Vendor/reseller tampering | |
Mail interdiction | ||
Embed device in another device | ||
At customer's install site | Evil user tampering | Live system intrusion detection (examples??) |
Routine pogo board testing | ||
Passive monitoring, e.g.,
|
??? |
March 27, 2021
Still looking for a non-BGA ARM processor that contains two Ethernet PHYs and has 0.5mm or greater lead pitch (for Voltera V-1 PCB production. We are now considering three options for design:
- (A) Non-BGA ARM processor on a homemade mainboard [simplest but limited to non-gigabit speeds; may require SW porting]
- (B) BGA ARM processor on a fabbed carrier board attached to a homemade mainboard [more complicated but higher performance and easier to source; may avoid SW porting]
- E.g., NXP i.MX6SoloX
- Unpopulated carrier board will need to be examined, probably via x-ray, after production
- Carrier board reflow is still done by us
- Still need to look for more ways to increase provenance
- (C) Use an existing open source BGA-based project (e.g., Kosagi Novena) and modify it for trusted manufacturing [complexity likely between (A) and (B)]
- Will still likely need a BGA carrier board from (B) but may reduce R&D costs of the project
Infrastructure
We’ll be setting up an IRC server in parallel to testing local deployment of the Element secure chat system.
March 20, 2021
In order to make forward progress on the hardware, we will choose OpenBSD as the initial operating system and an ARM-based architecture for the CPU. Users will be able to use their own ARM-compatible OS if they choose, including Linux and Plan9 (if software support is added).
We will first create a Software-Intent Proof of Concept (SIPoC), which will be an OpenBSD-based router running on a commercially available SBC. We may then want, as a Proof of Concept (PoC), to port the software stack to the Common Networks nodes at Noisebridge and begin deploying them across sites.
The first version of our custom hardware should be amendable to DIY manufacturing. This means no BGA parts. This severely restricts the list of CPUs/SoCs to older and lower-performance chips, limiting our capability to 100MBps initially. We'll expand this list as we discover more:
List of non-BGA ARM SoCs
Current leading candidate: Nuvoton NUC980DR61Y - 64-eLQFP 0.5mmPros: Low pin count, has 10/100 PHY, 64 MB SiP RAM, HW crypto, relatively cheap (~$10 low qty)Cons: No native OpenBSD/NetBSD support, no video out, RAM may be tight, 0.5mm pitch is tough with Voltera, no USB 1 port (USB 2 needs 1 GHz scope for debugging)Open source sample codeReference schematics & design docs- Dealbreaker: Only one PHY on 0.5mm package
- TI AM1705 - 176-PQFP 0.5mm
- NXP i.MX233 - 128-LQFP 0.4mm
- Allwinner V3s - 128-eLQFP 0.4mm
March 13, 2021
- Looking for secure communications platform for project collaboration. Element / Matrix look promising.
- Possibly partner with CircuitLaunch for local hardware builds?
March 6, 2021
Initial meeting. Discussed range of HW/SW design choices.
Tentative Project Stages
- SIPoC: OpenBSD router on commercial SBC
- PoC: SW stack on Common Networks
- Proto 1 build: Low-speed (10/100 Mbps) DIY version
- Full build: 1 Gbps
Possible Design Choices for Future Versions
- CPU
- ARM/ARM64 SoC
- RISC-V SoC
- FPGA
- Specifically no Intel/compatible architectures due to poor security record
- OS / Application Code
- OpenBSD
- Qubes
- Alpine Linux
- Plan9
- Custom FPGA code
- Trusted manufacturers
Open Questions
- How to offer root-of-trust guarantees to non-DIY customers
Meetings
We are currently (as of March 2021) meeting every Saturday at 14:00 PT (GMT-8) on the Noisebridge Jitsi video platform.
Links to Resources
- Related projects
- Kosagi Novena - bunnie Huang's open hardware ARM SBC with OpenBSD support and dual Ethernet
- Linuxstamp – open source non-BGA ARM9 Linux-capable SBC with 10/100 Ethernet on a 2-layer board
- EthernetFMC - open hardware GigE transceiver with RGMII interface based on Marvell 88E1510 chip
- Deprecated projects
- SecurityRouter - OpenBSD distro for network management
- Other OpenBSD-capable boards
- Raspberry Pi
- Pine64 PineBookPro and RockPro64
- NanoPi R4S
- Software & firmware
- Libreboot - freedom-respecting boot firmware
- Other architectures
- OpenBSD on RISC-V: Porting OpenBSD to RISC-V ISA (PDF), GitHub repo
- Mill Computing - novel CPU design in the North Bay
- Communication & collaboration platforms
- Element / Matrix - open source, distributed, secure chat
- Wire - open source, secure chat
- Scuttlebutt - open source, distributed, secure social network
- Gitter - open source chat
- Hardware manufacturers
- Design tools
- KiCAD - schematic capture and PCB layout
- Anti-tampering
- Transparent PCB manufacturer
- Tamper evident markers
- Wikipedia article on Tamper Evident Technology
- "Open Source is insufficient to solve trust problems in hardware" by Bunnie Huang (video presentation)