151–160 of 195 posts
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.
Any 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
Earlier 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…
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…
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.
Earlier 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.
Can a tamper event be triggered through software? It would really simplify the ability to create trap passwords which wipe the device.
This doesn't seem all that secure. Against an Evil Maid attack, your best mitigation is to be able to keep everything, OS and all, on a portable drive which is self-encrypting; essentially an encrypted PE.
Does that work? Can't the evil maid install a malicious hypervisor to dump interesting pieces of memory every few minutes?
Earlier quoted context omitted.
Interdiction could happen with open source hardware too. Swipe the SoC, and no one would be the wiser. Given everything that has to be in place for vPro/the ME to work, looking at the pcb would give enough information to tell exactly how much, if any, information it could steal, if all the malicious items were in place. All of which could be easily undone by reflashing it, because the write line on the bios is not co…
> 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…
The proximity based lockdown is interesting but won't prevent the likely scenario of being grabbed while you are using the computer. Silkroad is a famous incident, but I think its the only option in any scenerio where the attacker knows you are using an encrypted disk. 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 co…
Earlier 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?
The proximity based lockdown is interesting but won't prevent the likely scenario of being grabbed while you are using the computer. Silkroad is a famous incident, but I think its the only option in any scenerio where the attacker knows you are using an encrypted disk. 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 co…
Thank you for the feedback! This is still a desktop so if the device is grabbed the power won't stay long. You need NFC to restart and then enter your password. We are still working on opening as much as we can of the design. Bill of Material and drawings will be detailed on www.orwl.org/wiki
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_...
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 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.