5 ms·

Having some physical security in a OSS-hacker-compliant form factor is really quite nice. This is not going to replace a proper HSM, and almost certainly is a l

Having some physical security in a OSS-hacker-compliant form factor is really quite nice. This is not going to replace a proper HSM, and almost certainly is a less secure place to store your data than an iPhone; but it's a good start for those unwilling to give up on (the performance of) PCs. 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...)

deleted 10y ago
[deleted]
tajen 10y ago
Why is it potentially less secure than an iPhone? Attackers can't scan the RAM because of the enclosure, whereas they might do so on an iPhone, correct?
- VoidWhisperer 10y ago
  Correct me if I am wrong, but if that was possible, wouldn't the FBI have had a lot less of a challenging time getting the data off of that guy's phone?
  - krapp 10y ago
    They didn't have a challenging time, they just paid some hackers to do it[0]. 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-idUSKCN0XI2IB http://www.reuters.com/article/us-apple-encryption-fbi-idUSK... [1]https://www.theguardian.com/technology/2016/feb/25/fbi-director-james-comey-apple-encryption-case-legal-precedent https://www.theguardian.com/technology/2016/feb/25/fbi-direc...
talltower 10y ago
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 device. The scanning of RAM content and possibilities of EM scanning, side channel attacks are all covered in the secure section of ORWL by the Maxim Secure controller. Nothing is impossible, but we tried to make it really really hard to get hold of the SSD encryption key and what we refer to as the Root of Trust. Qubes is really helpful with many other attack vectors.
- a3n 10y ago
  If you guys succeed, you should think about making phones.
  - talltower 10y ago
    We are actually talking about this. Thanks for your interest.
    - i336_ 10y ago
      If I can get a word in on this subject, I'd like to say this: 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_mcafee_ama/cu9ycin?context=4 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.
a3_nm 10y ago
> almost certainly is a less secure place to store your data than an iPhone How can this be assessed when we don't know the code that runs on an iPhone?
- cies 10y ago
  He covered himself by using the word "almost". :) I agree with you, I'd choose to rephrase the quote to: > most uncertainly an iPhone is a secure place to store your data

deleted 10y ago

[deleted]

tajen 10y ago

Why is it potentially less secure than an iPhone? Attackers can't scan the RAM because of the enclosure, whereas they might do so on an iPhone, correct?

VoidWhisperer 10y ago
Correct me if I am wrong, but if that was possible, wouldn't the FBI have had a lot less of a challenging time getting the data off of that guy's phone?
- krapp 10y ago
  They didn't have a challenging time, they just paid some hackers to do it[0]. 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-idUSKCN0XI2IB http://www.reuters.com/article/us-apple-encryption-fbi-idUSK... [1]https://www.theguardian.com/technology/2016/feb/25/fbi-director-james-comey-apple-encryption-case-legal-precedent https://www.theguardian.com/technology/2016/feb/25/fbi-direc...

talltower 10y ago

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 device. The scanning of RAM content and possibilities of EM scanning, side channel attacks are all covered in the secure section of ORWL by the Maxim Secure controller. Nothing is impossible, but we tried to make it really really hard to get hold of the SSD encryption key and what we refer to as the Root of Trust. Qubes is really helpful with many other attack vectors.

a3n 10y ago
If you guys succeed, you should think about making phones.
- talltower 10y ago
  We are actually talking about this. Thanks for your interest.
  - i336_ 10y ago
    If I can get a word in on this subject, I'd like to say this: 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_mcafee_ama/cu9ycin?context=4 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.

a3_nm 10y ago

> almost certainly is a less secure place to store your data than an iPhone How can this be assessed when we don't know the code that runs on an iPhone?

cies 10y ago
He covered himself by using the word "almost". :) I agree with you, I'd choose to rephrase the quote to: > most uncertainly an iPhone is a secure place to store your data