made a product like this before that passed FIPS 140-3, same idea, i.e. a battery-backup-mcu + mainboard.
ORWL – The first open source, physically secure computer
141–150 of 195 posts
Re: ORWL – The first open source, physically secure computer
#142Earlier quoted context omitted.
There is a section at the end of the page outlining mitigation techniques against these sorts of attacks. I'm not knowledgable enough to determine if these are sufficient measures but I just wanted to point it out since it sounds like you didn't see that. They specifically cover cold boot attacks for example.
Right, OP was asking why having physical access to a "normal" machine means pwnage: cold boot is one of those ways. The ORWL page describes how they mitigate that.
Oh I see, thank you.
Re: ORWL – The first open source, physically secure computer
#143Now this is really cool! Though as with all things wireless I'd worry about working and somehow the key fob getting interfered with and boom computer locks up or if a sensor thinks I'm moving the computer when it's really just an Earth quake or maybe even my cat jumping on the table and then the encryption key is deleted. So I love the idea but not sure of the practicality. Those sensors has to essentially work perfe…
The SSD encryption key will only be deleted in case of a tamper event, NOT when the unit is moved. Tamper events are: * freezing the unit * drilling the secure enclosure or other wise breaking the traces on it * prying the enclosure off the PCB So I don't think you have to be too worried about a false trigger of a key erasing.
Is there a specific temperature about which I should be concerned? I live in a cold climate and would hate to lose data (even if it is backed up) in the event that I lose heating.
Re: ORWL – The first open source, physically secure computer
#144Earlier quoted context omitted.
quantum computers, at best, divide the bit-strength of a symmetric key like AES in half[1]. Brute forcing a 128 bit key is theoretically possible (in the sense that you can do it if you marshal the entire world energy output to the cause, you could crack 1 key/yr), but not a 5 minute process. [1] https://en.wikipedia.org/wiki/Grover%27s_algorithm
that is assuming that there is no better quantum algorithm for aes specifically. grover's algorithm is only optimal if brute force search is the only possible approach and there are no other exploitable properties. 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…
It's very obvious how special structure exists in cryptosystems that use finite cyclic groups, such as in discrete log cryptosystems.
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.
Re: ORWL – The first open source, physically secure computer
#145Earlier quoted context omitted.
Kudos to the open source design but they should not encourage users to run windows on it.
The promotional video shows someone using Linux. Do they mention Windows somewhere else on their site?
They mention Windows compatibility as an explicit and mandatory goal of the project in the Crowdsupply project page.
Re: ORWL – The first open source, physically secure computer
#146Earlier quoted context omitted.
He's talking about display monitors AKA the screens which can be exploited via the i2c bus over the graphical interface (e.g. HDMI). 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…
I'm a bit surprised that, in 2016, there is no standard way for a computer to authenticate its keyboard and monitor. Has anyone even thought about how that could be done?
yes but since an application is DRM the hacker groupthink decided that this was a double unplus good thought and so no one should think it lest evil happen.
Re: ORWL – The first open source, physically secure computer
#147I'd be very interested to see this applied to phones.
Re: ORWL – The first open source, physically secure computer
#148Earlier quoted context omitted.
This is an example of someone reprogramming the monitor, not using a monitor to attack the computer that it's connected to the video-out of. I'm not clear if there's an attack against the ORWL itself you have in mind here.
Once you reprogram the monitor, you can store or exfiltrate all of the data the user sees, and do clever things like erase and redraw the mouse pointer, or draw new prompts, to induce the user to click on the things they wouldn't have otherwise.
Or the one I coinvented and described before the leaks:
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).
Re: ORWL – The first open source, physically secure computer
#149How do they deal with the intel management engine in all intel chips? https://libreboot.org/faq/
In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. If you don't have such a network interface, the ME can't do all that much, and any adverse security risks are near zero. Add to that things like the firmware write line being controlled by a completely separate microcontroller, and the big things that are discussed are completely infe…
"In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. "
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.
Re: ORWL – The first open source, physically secure computer
#150Earlier quoted context omitted.
Sadly the T1/T2 are ancient now. The non-open SPARC is up to T7, which is 20nm process, 256 threads on 32 cores.
Sort of. I run the bloated Web, movies, IDE's, servers, and VM's on a Core Duo with 2 cores under 2GHz done on 65nm. I'd loose some single-threaded performance probably with an OpenSPARC T2 but otherwise it should handle my modern workload. Doesn't quite feel ancient. ;) 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 b…
As a 2011 MBA user, I totally understand sticking with old tech that works. T1/T2 isn't really apples-to-apples, though. I came across this random quote from the libgmp devs that made me laugh:
"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!