ORWL – The first open source, physically secure computer
crowdsupply.com
crowdsupply.com
It's worth noting that QubesOS, which is supported by this system, protects against e.g. USB-based attacks by running a virtualized Linux for just the USB port (simplified.) This has its limitations, but should be pretty decent.
If at all possible, try to ensure that this device is powered down when an attacker gets it. Several attacks are easier if that's not the case (e.g. USB-based attacks, but also cold boot attacks on the encrypted disk - the security monitoring should trigger when one opens the case, but if an attacker can still extract your disk password from RAM before the RAM fades you're in trouble...)
What they wanted was to set a legal precedent[1] which would allow any law enforcement agency to force manufacturers to subvert the security of their devices on demand.
[0]http://www.reuters.com/article/us-apple-encryption-fbi-idUSK...
[1]https://www.theguardian.com/technology/2016/feb/25/fbi-direc...
If Android is stripped completely back to minimum and rebuilt fully from source, it's arguably a trustworthy platform, but who has the time to basically do the equivalent of Gentoo on their phone, potentially weekly?
Even if the binary blob problem was miraculously solved, a rooted android device is basically a sitting duck (https://www.reddit.com/r/netsec/comments/3hr9f0/i_am_john_mc...), but an unrooted device isn't sufficiently hackable (flexible) to ensure its continued security (ie, unrooted + depending on a central service for Android updates = no thanks).
To me, I personally don't equate "Android" with "secure" in any way shape or form; I consider the platform practicably unsecurable.
I was just doing a bit of thinking. How about: use the 100MHz secure processor to run Linux or some another open-source lightweight kernel, and add a second CPU (something run-of-the-mill but decent, 1GHz+) that the first one can switch on and off. Both CPUs can see the GPU (running a low-res display, to make it easier - and cheaper), controlled only using open drivers, and the CPUs arbitrate for who has control of the GPU.
I see two software use cases for such a model.
First, you could use the 100MHz secure processor to actually run the phone. The resulting UI would be pretty basic, but open and verifiably secure (this is not currently possible with any other device AFAIK, and would get you a noteworthy demographic). You could use the 1GHz+ secondary CPU in lieu of hardware GPU decode - as in, you setup the fast CPU with libx265 on a unikernel, and feed it data via DMA. That sidesteps the blob problem, and lets people securely chat via/watch video.
Second, you could use the secure processor to do basic system tasks (again, providing a minimal UI), and provide an option to boot Android on the second processor. Caveat emptor, but that would cater to the people who only want to go so far, and all on the one piece of hardware.
Hmm. A modem is just straight CDC with no weirdness, right? Also, are there cellular-class Wi-Fi chipsets with open drivers out there?
To me, I absolutely envisage a secure phone as a secondary device. I might not want it in my possession all the time. Under certain circumstancs it might make sense for me to do a lot of activity on another phone so I do generate decipherable noise. I might want different/unusual notification policies (eg, maybe calls shouldn't even vibrate under certain circumstances).
The above is just me in stream-of-consciousness mode - but I've personally wanted a truly secure communicator for a very long time, not because I actually have anything to hide, but because I find the idea of being able to achieve near-perfect security (in particular, secure boot) really compelling.
I can understand why x86 was the only viable solution for the desktop, and kudos for just going ahead and making the effort with that design. I think that for mobile communications, being able to send and receive simple text messages using a secure hardware design that's running carefully-vetoed software would just be really really cool.
PS. Host USB would be incredibly useful. I really like your idea of having the port lock down though.
How can this be assessed when we don't know the code that runs on an iPhone?
I agree with you, I'd choose to rephrase the quote to:
> most uncertainly an iPhone is a secure place to store your data
https://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c16.pdf
Best route is just to clone that thing somehow. IBM themselves already depreciated it in favor of a new product. Might still try to patent sue you or pull some other crap but worst case should be Chinese clones becoming available after new design is published. :) Designers of ORWL should try to copy more of the IBM thing's techniques to close gap between the two.
Far as design itself, I like that it's relatively simple, leverages a secure IC, easy to disassemble, will allow low-level modifications like firmware, and can run standard software. The next step will be a model that replaces the Intel chip with OpenSPARC, OpenPOWER, or RISC-V multicore with added components for trusted boot or I/O protections. Some are available with some coming online. Next step is using crypto to protect confidentiality & integrity of anything leaving SOC boundary so RAM is untrusted. There will be a lot of money involved for initial development and prototyping of even the first, open chip. So, I understand if they're taking it one step at a time. That's cool as long as they keep the advertising honest about risks they're keeping in for compatibility, etc.
It's worth mentioning that there is at least one OSS implementation of a TEE software stack, OP-TEE, making this even less of an issue. Assuming your device/soc mfg doesn't lock you out.
http://www.linaro.org/blog/core-dump/op-tee-open-source-secu...
AMD has something similar to the Intel Management Engine: https://libreboot.org/faq/#amd
http://www.oracle.com/technetwork/systems/opensparc/openspar...
The ASIC implementation was nice:
https://en.wikipedia.org/wiki/UltraSPARC_T2
On a 65nm node... very outdated one... it might get 8 threads in 8 cores at 1.6GHz each with hardware RNG, crypto accelerators, and hypervisor support. That's the kind of implementation that would be useless for an open-source, secure workstation, server, or HPC node. ;) Especially if one slightly increased single-core performance or cache when porting it to 45nm.
Forget that, though. Let's see what IBM will charge for their admittedly-faster pile of complicated silicon that only certain people can see which they've already turned into non-backdoored chips for you. ;)
The cool thing about open-source CPU's is one can always improve on them to, say, have an extra dozen cores on more recent nodes. Like Oracle does but probably less impressive with less money.
"SPARC chips before T4 under-perform on GMP. This is not because the GMP code is inadequately optimised for SPARC, but due to the basic v9 ISA as well as the micro-architecture of these chips. The T1 and T2 chips perform worse than any other SPARC chips; they compare to a 15 year older 486 chip."
ouch!
Note: There's always my other recommendation of turning open-source Leon3 into a multicore. Im curious what it or Leon4 get on such a benchmark versus Intels on similar process nodes.
Somebody tried to use a university department's T2 because it was unused and reasonably parallel for some experiment on hashing.
Single core SHA1 speed on a t2 was ~300KB/s or so. Even with its 32 threads I recommended going for any ancient desktop that happened not to be used for a couple of days because the experiment would finish much faster there. Those desktops were about Core Duo class and managed 50-100MB/s SHA1 throughput (I think, it's been a couple of years).
This project is about having a standard, physically secure computer that anyone can use – as open as we can make it. All these concepts are important, and they mean that x86 and flawless out-of-the-box Windows support are not optional. There are reasons everyone is using x86, even in the security community and in governmental agencies around the world: compatibility, performance, and security. Make no mistake, some of us own Yeeloongs, and others are veterans of the silicon industry. We would love to ship a completely free and usable desktop processor, but we know very well that there is no alternative. Some people seem to think that switching to AMD can solve problems related Intel’s Management Engine (ME), microcode, or SMM. It doesn’t, as there are equivalents of these technologies in all recent x86 processors.
How else is there any progress when the community's just pulling everyone down with this "it's no good if it isn't completely perfect" crap?
The parent comment is right to point out this computer has a fully functioning Intel ME, running it's secret, unaudited, possibly backdoored, firmware on the co-processer which runs even when switched off, and can interact with the rest of the system undetected. Any "secure" system with this foundation isn't really secure.
IMHO a product which would focus more on this (like libreboot laptops) can make a bigger claim on doing something for security than this.
...have to trust Intel's publicly available documentation. In other words, this has to be taken on pure faith that it does exactly what they say it does in exactly the way they say it does it, and no more.
The problem with ME is that it consists of unauditable code that could be doing literally anything on the computer, completely transparent to the user. Furthermore, even if there is nothing untoward happening when the chip leaves the fab (again, must be taken on faith), a documented threat is having hardware interdicted, modified, and sent on its way.
It would have to get swiped on the way from the manufacturer to the OEM. Once the OEM has sent it out, it's protected against this exact kind of attack. And while it may make sense for interdiction of a single package to a known target, doing the same with an entire batch of chips seems prohibitively expensive.
>Given everything that has to be in place for vPro/the ME to work
Again, per Intel's documentation. For all anyone here knows, data exfil begins the moment a certain sequence of bits crosses the right registers - and it's not like this is beyond the capabilities of what ME lets you do.
There is no good reason that the entire subsystem can't be disabled by the user, permanently. But, come to find out about it, the chips are configured to shut the system down within 30 minutes if the ME firmware doesn't pass checksum.
That, in my mind, puts it uncomfortably close to malware territory. Every one of these concerns evaporate if the ME area could be wiped or dumped - it's not as if remote management is some secret competitive advantage.
The point I'm trying to convey here is that every piece of information available on this thing comes straight from the horse's mouth, and the horse is not necessarily a trustworthy actor.
https://www.orwl.org/wiki/images/9/95/SowDESIGN-SHIFTORWLPUB...
For both ME and debugging purposes, Intel's chips are wired through and through in ways that could do interesting things in the hands of an attacker. ME gives attacker the ability to act. What you just said is you believe Intel's technical statements and marketing claims about that. In reality, you can't know about any digital, analog, or RF backdoors it creates unless you get whole thing torn down at transistor level with analysis by people who understand all those categories. It's normal in ASIC work, for trade secret protection and dodging patent suits, for firms to use tricks to hide I.P. in I.P.. They also reduce NRE & mask costs by putting circuitry in whole families of product while only visibly enabling them in some at factory. Still there, though. The guy that originally taught me about this stuff gave an example where one component they used had wireless connectivity because it was a mobile SOC where they visibly, but only temporarily, disabled some components to make it look like a microcontroller and I/O combo. They were trying to score extra ROI off it without building dedicated product.
Lots of stuff like that in ASIC design. Hell, the firewall industry should've already taught all of you this lesson. Grimes reviews of them showed they often had all kinds of undocumented stuff running that wasn't advertised but was result of poor quality or some internal benefit. He rarely ran into one that did what it advertised and only what it advertised. That wasn't even open-source testing. ;) Intel's stuff is a combo of their specs, their implementation, the analog circuits, the effects of the materials involved on those, and the interactions with other things on the board if you're talking EMSEC. There's no way for you to verify these are secure by reading their public claims. This is neither a new nor uncommon problem.
The GP is 100% correct, if you can't trust your keyboard, mouse, and the monitor the "secure computer" concept in this case is problematic, while it does reduce the attack surface somewhat it just focuses the attention of the adversary onto a different vector.
If we take their "cleaning man/evil maid" scenario then while implanting the computer might not be possible, implanting the keyboard, mouse or screen would be very possible, and in fact somewhat easier than implanting a regular computer with decent security measures such as an encrypted drive.
Add a USB storage device with a micro-controller to the keyboard and you own the computer once it's connected, a monitor today comes with a CPU powerful enough to run custom code which can be used to exfiltrate data as well.
Additionally both the keyboard and the monitor could potentially be used to exploit software flaws on the software running on the ORWL unit also.
The concept is interesting however this is mostly "security theater" any adversary which would be sophisticated enough to require taking these measures would likely be able to circumvent them, and for the rest these measures don't really do anything; if you use this for day to day operations or on-net activity you'll get pwned via the network; if you keep secrets on this thing worthy of sending some one into your home to implant your PC then they'll implant something else which is connected to it.
Oddly enough the only "high tier" adversary that this might thwart would be law enforcement since their computer forensic SOP would pretty much melt down when encountering something which is tamper resistant.
But hey, you gotta start somewhere.
If you are going to prevent physical attacks from adversaries that can circumvent basic protection (e.g. FDE) you have to make sure that every device is as secure because the system is as secure as its weakest link.
If your adversaries are just the random person that might steal your PC then any full disk encryption even a cryptographically insecure one would be sufficient because the people who end up dealing with these devices won't have the knowhow or the resources to attack even bad encryption.
https://www.schneier.com/blog/archives/2014/03/ragemaster_ns...
There's no direct solution to the subverted monitor problem that I'm aware of. You basically get them from random places under different names or from people unlikely to be spies then use I/O protection both ways. Same with most hardware you can't produce yourself. There's potential to market something here where the monitor is immune to code injection, does I/O filtering, can't store anything, and does these with visually-inspectable chips & board. Add TEMPEST shielding while you're at it since that's an existing market that will drop lots of cash on improving security. See EMCON's products for examples.
EDIT: Forgot to mention that spectrum analysis is often used to try to catch radio emissions. There's techniques to tell if monitor sends out stranger than usual signals. That's just kind of limited and doesn't help if it's black bag job where person can show up twice (eg maintenance person).
I'm curious about your supply chain risk mitigation. Given that the project is open source, can you publish a list of all of your suppliers and the country of production?
Great work overall, looks like a nice design.
I noticed the campaign details indicated the power supply voltage is monitored. Will this protect against a hot-plug?
[0]: http://www.cru-inc.com/products/wiebetech/hotplug_field_kit_...
I suppose this technique could be modified for most UK pugs too, but I've no idea how you'd manage it for a recessed EU-type socket.
So I love the idea but not sure of the practicality. Those sensors has to essentially work perfectly at all times and I'm not convinced until it's released and reviewed.
It seems like a lot of the security of the device depends on active scanning (e.g. the LDS clamshell mesh, the IMU, the temp sensor, etc.), which stops working after 6 months. Is the vector of a malicious actor taking the device and waiting 6 months before breaking in considered not worth protecting against?
Err, why? Is AES encryption not sufficient? And the key is secure in my head - not something someone could steal.
So, why is this even a thing?
Just a thought.
You might as well have the entire computer removable and portable.
But if I know the attack took place (FBI broke into my house, the computer is locked in a safe etc.) - the data should be secure.
They specifically cover cold boot attacks for example.
With slight modifications (* ) this sounds like a low cost, but easy to deploy solution to the problem. Some of the security would be lost, but you would still get a reasonably tamper proof computer that is capable of running standard software stack for <$1K.
With the same kind of changes you could also build a low cost HSM solution based on this.
(* ) Instead of controlling booting, the keyfob could be used to enable/disable console access and the device should be able to recover from short power losses.
and...
Upon any tampering, the secure microcontroller instantly erases the encryption key, causing all data on the SSD to be irrevocably lost.
If only the key is deleted, wouldn't that leave the drive susceptible to brute force?
See you in a few trillion years.
tl;dr if all the matter in the whole universe was a computer, it'd still be unlikely.
Moore's Law doesn't really factor into it.
I'm a bit surprised the quantum algorithm only gives a polynomial speedup.
[1] https://en.wikipedia.org/wiki/Observable_universe#Matter_con...
2^256 = (2^10)^25.6 = 1024^25.6
These number seem very close.
NSA Manager: Connect it to the quantum computer that doesn't "exist".
Five minutes later..
NSA Engineer: We now have access.
considering that there already theoretical attacks that (marginally) faster than brute force on classic computers who knows how much more one could squeeze out with quantum algorithms.
Of course those are fairly speculative concerns.
But in AES? that sounds unlikely and really unfortunate.
I think it's more likely that large quantum computers would aid in mathmatical exploration that uncovers currently unknown vulnerabilities that could be exploited by classical systems.
If they were serious, I'd say work with Genode team for FOSS or partner with Sirrix to port their TrustedDesktop system to it. Both are using models with low TCB's and trusted paths architecturally similar to B3/A1 systems. Turaya used by Sirrix is basically Perseus Framework with pre-built drivers, VPN, disk crypto, management software, etc. Batteries-included. Here's Perseus:
http://www.perseus-os.org/content/pages/Overview.htm
I think a port of TrustedDesktop to ORWL-like solution would be a nice start on secure desktops for businesses or individuals willing to pony up dough. Can use something like Genode once it gets mature enough with necessary components. I've moved on from separation kernel stuff to HW-centric security but combining a thing that works with one that might seems like a good default for now.
So, a Turaya-like product combined with ORWL. I'll add requirements of parsers auto-generated LANGSEC-style with any TCB code run through SAFEcode or Softbound+CETS at a minimum. Kernel on bottom is seL4 or Muen (SPARK). Drivers done statically in subset of C or SPARK amendable to thorough analysis. Would that strategy for rapidly getting a high-security product out the door address most of your expectations or exceed them?
[0] https://insights.ubuntu.com/2016/09/29/meet-orwl-the-first-o...
IMHO that is beyond stupid, it's criminally irresponsible.
Well, to be fair, perhaps there are some uses cases, just not many. I'd rather go with tamper-proof seals instead.
There is always a tradeoff between security and data integrity, something which the people who downvoted my post apparently don't understand. When even your mom can mount a 100% successful denial of service attack with a screwdriver, then you're screwed.
If you disagree, I challenge you to show me a use reasonable case that couldn't also be solved by actual physical security or by locking down booting and the BIOS and using tamper-evident seals.
For ordinary users, deleting everything immediately when someone tampers with it is a recipe for disaster. Sure, they can backup everything in encrypted form, but then the data is not really deleted when somebody tampers with the machine, isn't it?
Regarding the security, well, apart from software-based attacks, how about installing a tiny USB keylogger inside a USB cable that is already used by the user? Or in the keyboard itself? Or a camera that records your keystrokes?
That's what the <insert agency or special interest group of your choice> would be doing in such a case.
Not all products are the same. It's irresponsible, but maybe good business strategy, to presume a complicated computer, which runs software that no human can hold in their head is the same as other products people are accustomed to.
Doesn't help when the tamperer isn't hiding
Secure computing cannot and will not move forward until we have a way to mitigate against this.
Seems like using built in input and display and giving up some external ports would be the only reasonable strategy if you were being as serious about physical security as this wants to be.
Also, such a device can be combined with a secure, open computer to divide risk up among software and physical attacks.
I'd be more concerned about the wifi and bluetooth chips' firmware.
We could express the same idea without the power and gender relations implied.
Also technically whilst it does originate from maiden it is mostly gender neutral today, just like busboy or a bodyman are.
If you haven't heard the phrase before it sounds weird, I do understand it's not intended maliciously.
I don't think I'd use the term without quotes in my own writing.
Why would you even think of this as an issue? I had to read your comment, then read the replies, then read your comment again, twice, in order to actually understand what you were saying because it made literally no sense to me that anyone would have a problem with this.
Why does it matter? There are plenty of words that used to mean something and now mean something completely different when in context.