We thought long and hard about the type of platform we want to use for this project. While the x86 platform has many shortcomings, it also provides a big ecosystem of OS and SW, as well as support. The fact that we have two subsystems, secure micro controller being in charge of supplying (and denying) power from the x86 gives us a lot of leverage and protection.

Yes, HSMs are very expensive and after talking to a few people in this industry we got the impression, some of the ORWL features are not present in HSMs. Like the ability to Geo-lock the device using the key (mounted in the ceiling). Waling away with the device will render it useless as the keyFOB is missing.

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.

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...

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...

Yes, physical access in most cases is a point of no GOOD return. That is why we emphasize so much on preventing this access. We have detailed the measures we have taken to prevent this here: https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.6... Look at section: "ORWL Primary Key of Security or Root of Trust"

Yes, correct. We think we cover the cold boot vector. Here is a section from the product description. Security mesh physically protects DRAM from both freezing specific components and removal. Breaching the mesh will trigger reactive root key delete and system power down. Secure Microcontroller protects against chilling the full device - temps below -37℃ will trigger a tamper event, deleting root key and removing power from system. Link to the complete Product Description: https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.6...

Correction. The temperature monitor is INSIDE the secure shell.

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 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.

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?

HDCP is arguably the standard for authenticating the monitor, but it's not quite intended for this purpose. I'm not aware of a standard for authenticating input devices, but disabling USB HID and relying solely on tamper-evident PS/2 input devices goes a long way.

Even if you can, yous implant a keylogger onto the keyboard, and some malware/implant into the screen you get a full readout of every keystroke and every pixel displayed.

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.

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.

GP probably means display monitor, not temperature monitor.

I do mean display monitor, not temperature monitor.

Thanks for the correction. I was not sure at the time.

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.

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.

so if I live in a cold place and take it outside then it might erase my data? or what yellowapple said about losing heating, if I live in a really cold place; if pipes can go below 0 C due to cold temperature, why can I expect that ORWL won't?

Can a tamper event be triggered through software? It would really simplify the ability to create trap passwords which wipe the device.

Particularly by overheating the processor or other components like one might do if melting stuff off the outside with flame or acid application.

I was hoping for something a little more direct, deterministic, immediate, and non-damaging.

Let me state a section of our product description here, detailing the way we are approaching the "Evil Maids" USB volume boot blocked at BIOS, BIOS access controlled by security key + PIN, Intel TPM is enabled, and we do not enter a passphrase to unlock encryption (unlike software based full disk encryption) In addition, attacks that don’t rely on booting to a USB device are protected by powering off the USB interface when the user keyfob is out of range More details here: https://www.orwl.org/wiki/index.php?title=Resources#Resource...