Slashdot Mirror
Physically-Secure 'ORWL' Computer Expands Its Open Source Policy (crowdsupply.com)
Last month DESIGN Shift successfully crowdfunded their physically-secure (and open source) ORWL computer. But this week long-time Slashdot reader Dr. Crash raised concerns that "releasing only the equivalent of 'assembly code' (PDFs of the schematic, Gerber files) and requiring an NDA for the BIOS and mechanical security just doesn't cut it... " Slashdot contacted the company, which two hours ago posted a response:
After feedback from some of you and more internal discussion, we've decided to open the schematics source files under CC-BY-NC-SA 4.0... Our reasoning is that the benefit of being able to much more easily inspect the inner workings of ORWL far outweighs the minimal risk of infringement by a third party. Even if a third party does decide to copy ORWL for profit, they would quickly discover the real work is in the layout, not the schematic, as is the case in most hardware...
[T]he firmware will be licensed under GPL 3 rather than CC-BY-SA 4.0. This change is in line with the Creative Commons's own recommendations regarding software licensing. We also realized that some of our firmware uses libraries provided under NDA. We will clearly identify which components are protected under NDA and how to go about securing such an NDA.
They've already released a .zip file of their schematics, and in addition announced that "we're committing to opening the PCB layout sources once we've sold a total of 3,000 ORWL unit." Their announcement includes a link for feedback from the community.
[T]he firmware will be licensed under GPL 3 rather than CC-BY-SA 4.0. This change is in line with the Creative Commons's own recommendations regarding software licensing. We also realized that some of our firmware uses libraries provided under NDA. We will clearly identify which components are protected under NDA and how to go about securing such an NDA.
They've already released a .zip file of their schematics, and in addition announced that "we're committing to opening the PCB layout sources once we've sold a total of 3,000 ORWL unit." Their announcement includes a link for feedback from the community.
So that means, everything is opensource, execept the BIOS and the Operating System. And that a Box with Windows 10 can only be "Physically-Secure" if you fill the case with cement and put it on the ground of the atlanic?
I'm actually impressed by this machine. Yes, a new NUC can probably do more, but the ORWL with a glass case is pretty impressive when it comes to security, especially if it can handle virtualization with the supported Ubuntu distro, so one can use it to run Windows 10 in a secure manner if need be. PCs designed for security from the ground up are not very common.
My only wish would be if they could add two ports for a fiber optic cable loop. This could be S/PDIF or any form factor. The goal is to have a fiber optic cable that could be looped around a desk or sturdy object, similar to a Kensington lock. If the cable is cut or unplugged, the machine goes into a locked state. This way, it turns the theft into "just" hardware.
This seems like bullshit. They tagged on encryption and wireless identification to create what looks like a fragile system that could decide to do a data wipe at any time. If you try to break into it, it wipes your data. I wonder if that's preventable?
Maybe you could couple an inductor to the hard drive ribbon to prevent signalling while you cut through the case (and ribbon), then extract the drive; but the key is probably stored elsewhere, and wipeable. There's got to be a way into this thing.
Support my political activism on Patreon.
Is that some sort of indicator that you are qualified to speak about a particular technical topic? That is the second time today that "Slashdot reader" was used in the same context you would expect to see "MIT professor" or "Boeing engineer" or a qualifier that actually means something.
This is an open invite and watch it be taken down like other companies in previous such boasts.
Because we've all read about how there's a built-in ARM core doing who knows what, out of the user's control. For all we know, it could send stuff over the network without us knowing.
> There's got to be a way into this thing.
If there aren't ways to get data in and out, it's kinda pointless as a computer. That's what computers do, of course, they accept input, process it, and produce output. So yeah, there are ways in.
Physically haven't seen the hardware, so we don't know what the "wire mesh" looks like - perhaps you could drill a couple of half inch holes through the case. Every $10,000 safe can be drilled without triggering the relockers, so you can bet that this can be as well. Most locksmiths drill to just unlock a safe; I drilled holes in the bottom of one and then completely disassembled the mechanism using long tools, like building a ship in a bottle.
For example, this computer has an HDMI port and two USB ports. I bet those aren't covered with a fine mesh screen, so you can probably drill them out and and start working from there.
We also realized that some of our firmware uses libraries provided under NDA. We will clearly identify which components are protected under NDA and how to go about securing such an NDA.
An NDA does not provide protection. What it does is confirm which parts of your machine and firmware cannot be trusted. Choosing to base their machine around an Intel chip was perhaps the greatest mistake they made.
Anons need not reply. Questions end with a question mark.
If the system is operating the ME has privilege over everything. Since I can't see the ME source code (or other intel-based chipset firmware) I can't verify it doesn't have intentional exploits in it.
Furthermore after the vPro cellular modem kill switch, I have to wonder at the possibility of the chips having a reciever inside the chip that can trigger exfiltration paths either directly off the cpu, or via the combination of Intel CPU and wifi adapter, since the particular platforms are well standardized.
All your claims about coreboot partitioning it off is bullshit if the actual hardware/unmodifiable firmware has those backdoors baked in.
This is right up there with the Purism laptop. If you guys had been serious about attemping this utilizing a fully open source firmware base there are still available AM3+ and possibly early FM2 (before the arm proc went in.) processors/chipsets available that would have made much more sense. The AM3+ route would even have included ECC support and optionally iommu support if you went with the 9(7|9)0 chipsets.
Your current offering however just reeks of security by obscurity, and we've all see how well that worked for Microsoft, Clinton, Trump, and thousands upon thousands of others.
Sorry for the length of the post, but I felt it was necessary. Until we start talking about the complete corresponding release of all the needed components like as what has been done with the EOMA68 project you can't even begin to talk about designing a truly secure computer. Intel and AMD are holding back important bits of code that we need to be able to examine to determine whether or not the remote control functionality includes a backdoor. We can be reasonably confident that these pieces do in fact contain a back door already given the circumstances and routine discoveries of backdoors in other types of devices in these sorts of proprietary components.
1. China's inserted backdoors into keyboard controllers and OS level components [first hand experience by people reverse engineering, and then accidentally having it confirmed by upstream Chinese manufacturers]
2. Unknown parties have inserted multiple backdoors into routers for what we can reasonably assume are multiple parties on routers
3. We know Intel and AMD are refusing to release the code modern Intel and AMD CPUs are dependant on which contain remote access functionality and there are good reasons to believe these companies are under gag orders not to disclose this one way or the other. We also know that manufacturers are being prevented from being able to properly disable this and because of signature checking reverse engineering would still result in code that could not be utilized in any practical way to bypass said backdoors.
4. Despite the issues with ARM we do have a sufficiently complete set of source code for the AllWinner A20 CPUs and EOMA68 compatible computer cards, laptop housings, and desktop housing have all been designed around this. Future quad-core CPUs are on the road map as well which could be utilized similarly in 6-8 months time.
While EOMA68 isn't a security solution in and of itself it's got all the critical pieces necessary for starting a serious discussion on designing secure computing systems. Now what is needed is for people to start reviewing the code, building/porting distributions such as Tails, and implementing hardening techniques. While X86 has some security enhancements that aren't possible on an A20 these systems must be presumed to be backdoored and therefore comprised out of the box. So you can't have a serious discussion about security thereafter. The next step to something better would probably be discussions about designing a CPU.
You forgot one important distinction: ORWL is a ready-to-ship pretty secure computer with a small amount of black-box parts. EOMA68 is a non-secure gedanken experiment with quite a bit of black-box parts if you try and actually implement it.
Insufficient. You still have nothing until you can audit the schematic-to-PCB translation, and audit the preboot (including BIOS, SMM, etc).
Without that, you can still fall to a port-knock with the digits of Pi, taking every fifth digit and grouping into a port number from 0 to 9999, starting at the 1,234,567,890th digit of pi. Or something else equally outlandish.
> attach some probe wires to the SATA
Once you have probes on the SATA pins, you can read the entire drive. Just plug the other end into the USB-SATA adapter on your laptop and dump the drive with ddrescue. If the ORWL isn't busy reading and writing to the drive at the same time, you won't even get errors causing ddrescue to retry those sectors.
> The encryption for the SSD is not stored in main RAM, it's stored in the SSD
Which is good in some ways, but bad in this case because as long as the drive is powered up, it remembers the key internally and decrypts the data for you - and you don't need to know the key in order to read the data after boot, only to boot.
It is very hard to implement a system that solves all problems at once, all done open source, without any involvement of any of the known software and semiconductor players. We are making good progress towards opening up closed code bases and hardware designs. I think Bruce Byfield is making this point much better than I can. https://t.co/pBeRkE7ajp Thanks
Thanks for the info and picture of the mesh. Looks like your team did a pretty good job. Nothing is impenetrable of course, but nice work.
From the pic, that looks like a micro USB? I have one here where I pulled out the board/contacts portion, leaving the metal shell, then drilled the top 1/3rd deeper to provide room for an extra chip attached to the replacement contacts. The assembly method used for some micro ports make it easy to pull out and replace the contacts portion- they hold the new contacts in with spring pressure. However, there's little room for adding a chip in a micro. Next I'm curious to see if any full-sized type A ports will allow the contact insert to be removed and replaced externally - there's a lot more room in a type A.
Yeah, I think you guys are doing a great job, sort of what IBM tried to do 15 years ago with their 4758, but failed due to hardware constraints (you had to run some funky embedded OS with equally funky IBM-specific development tools). The one thing that'd be nice to have is what someone suggested in a previous thread, a fibre-optic link that can be used to lock it into a physical location, so an attacker can't steal it and attack it at their leisure.