Did you think about manufacturing or designing your own ARM CPUs and releasing HDL for the CPU?
ORWL – The first open source, physically secure computer
181–190 of 195 posts
Re: ORWL – The first open source, physically secure computer
#182Earlier quoted context omitted.
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…
Some anecdata: 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 manage…
What the hell...??? Ok, it's looking like Im going to retract that recommendation for workstations. Maybe still servers thst are I/O bound.
Re: ORWL – The first open source, physically secure computer
#183Earlier quoted context omitted.
> Swipe the SoC, and no one would be the wiser. 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…
No, this is not per the documentation, this is per the physical specifications, the circuitry that needs to be in place, the support that needs to be in each component. The Management Engine is not as all-seeing as you make it out to be.
It's all seeing enough to poll the installed system for info on installed software, to have keylogger rootkits installed in it, and so on. This is all per the (exhaustively sourced) Wiki article.
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.
Re: ORWL – The first open source, physically secure computer
#184Earlier quoted context omitted.
ORWL will go in stand-by if the user is further than 10meters away from the device, if moved when away, it will shut down. If the hardware is tampered with, or chilled, the SSD encryption key is deleted within milliseconds. iPhone or any other consumer product at this point have less or no physical protection. The physical level of protection is taken from the payment industry standard and applied to the consumer dev…
what are you doing about offline attacks against the SSD crypto?
Offline this SSD is protected with "AES 256-bit Encryption". Simple Brute force attempts would need WAY too long to make any sense.
Does this answer your question?
Re: ORWL – The first open source, physically secure computer
#185Earlier quoted context omitted.
There's no such thing as "secure", and frankly complaining that anything that has better security than regular products shouldn't advertise as such is ridiculous. 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?
This product makes full disk encryption a bit more convenient, but that's about it. Even that turns something to know in something to have, which you could argue is easier to coerce someone into handing over. 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 c…
I respect your opinion on this.
We sought to build hardware that is a significant step up from what is available on the market today in terms of access control and tamper protection. We also open source the BIOS and customize it the most we can afford to minimize the ME capability thanks to Eltan's help.
Secure cannot be an absolute state, it can only be temporary... till the 1st one finds a way to get in.
Execution of non-auditable code is what we deal with on nearly every machine on the market. We are minimizing this, while still staying compatible with peoples use models.
We are as open and transparent as we can legally be. In our plan, this is only one step in the direction of taking back control of the machines we all are working on and want to trust completely.
https://www.orwl.org/wiki/index.php?title=File:SowDESIGN-SHI...
Re: ORWL – The first open source, physically secure computer
#186Earlier quoted context omitted.
That's all fine and good but they should not advertise it as secure if it's not.
They advertise it as "physically-secure" in the text. I didn't watch the video. They explicitly call out many risks, why they're there, and what they do about them.
We have built a list of hacks that we addressed and how. Please feel free to read up on all of these and more in our Product Description in the section "Potential attacks prevented" : https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.6...
Re: ORWL – The first open source, physically secure computer
#187Any plans to offer a 16GB RAM version? The commentary from Qubes users in the 3.2 release thread [1] seems to indicate 8GB would be borderline for Qubes. [1] https://news.ycombinator.com/item?id=12604417
The current Intel chipset we selected does only support RAM up to a max of 8GB. We heard the Qubes users loud and clear and the request for 16GB RAM. We will only be able to offer this in a next revision though.
Re: ORWL – The first open source, physically secure computer
#188Re: ORWL – The first open source, physically secure computer
#189Earlier quoted context omitted.
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.
what temperature (approximately) is "freezing" (or less likely, overheating)?
We currently have a Spec temperature of triggering a 'freezing event" at just above freezing Temperature 33-35F.
Re: ORWL – The first open source, physically secure computer
#190Earlier quoted context omitted.
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.
We currently have a Spec temperature of triggering a 'freezing event" at just above freezing Temperature 33-35F.