Arcadia LabsIn the HackaDay article about this box, someone raised an important question about security in the comments : he says not having OpenVPN on your own computer increases risks, because you have to trust the box. I disagree with him, here is why :
- This web security box is fully open source. So, everyone could check every component, every piece of software. This is a great advantage of open source.
- The user keeps complete control over security components : the RSA 1024 bits (or more) key pair is generated while installing the box for the first time, and the OpenVPN setup part is done by the user.
- If one couldn't trust the box OpenVPN software, he shouldn't trust an OpenVPN software installed on a computer either : it is the same software. Being installed on a PC is more risky in my opinion : many other components could break your configuration. The box is the opposite : you install it once, and don't add some non-related softwares all day long. So it remains very reliable (if you keep it updated).
- I don't like Apple much, but what if you want to use OpenVPN with a Mac ? You have to trust OpenVPN + Tunnelblick. One more component to trust. With the box, no problem : just connect to it, and voila !
- From professional experience, 90% computers have malwares, but a computer is hard to clean up. How could you be sure your computer OpenVPN endpoint could be trusted ? Do you know and check every bit of it (UEFI BIOS is an example) ? The box has no onboard BIOS, and is very easy to clean up : remove the SD card, format it, and restore your backup. It takes 10 minutes to restore a clean and working system.
- If you fear your box could be stolen or lost, and some hacker would use your OpenVPN software : just remove the SD card when you don't use it... The box alone is useless.
- If you fear some man-in-the-middle attack from the access point part : it is not less secure than your own internet router (this one you can't always trust because of proprietary softwares
- Essentialy, this box only uses unmodified OpenVPN / TOR softwares, custom iptables rules and some python interface. There's nothing one couldn't check by himself, there is no mystery component.
- The web interface configuration part is totally optional (but handy). If you fear the apache/php stack could be risky, don't install this part...
In my opinion, this box lowers the risk with having only one component to care about, as opposed to one component on each computer.
For an example : many times I had to work with this kind of PC softwares in big companies. It is a pain to maintain and to keep secure, when you have non tech people using it on many different machines and operating systems. The box solves this problem.
About the security technical details :
- Wireless access point is WPA2-PSK
- OpenVPN uses a self-generated OpenSSL RSA 1024 bits (or more) key pair and AES-256 encryption
- OpenVPN protocol is known to have no major vulnerabilities and is considered extremely secure
- PiModules UPiS could provide Extended Tiny Encryption Algorithm (XTEA) cryptographic Customer Software Protection System with custom defined protection keys, although it is not used in the current prototypes.
- SD-card remains accessible so you could remove it from the box. Nothing could be done without it.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Just Add Insecurity
--------------------------
Your assertion that the endpoint device might be compromised is a red herring. Let's examine the possibilities.
1/ The endpoint is uncompromised and this box is uncompromised.
2/ The endpoint is compromised and this box is uncompromised.
3/ The endpoint is compromised and this box is compromised.
4/ The endpoint is uncompromised and this box is compromised.
In the first case, user data is obviously uncompromised- there is no successful attack at play.
In the second case, user data is compromised before it reaches the UnJailPi. The fact that UnJailPi is on the network is therefore irrelevant: user data is still compromised.
In the third case, user data is again compromised, per the above.
In the fourth case user data is still compromised, since it can be seen in the clear by the UnJailPi.
So, user data is compromised in cases 2, 3, and 4. This is consistent with an at-face-value security assessment: to find the total amount of risk in the system, you *add* the amount of risk introduced by the endpoint to the amount of risk introduced by the UnJailPi.
Open Source != Fully Secure
---------------------------------------
There's another, related claim on the project page: that since the UnJailPi is fully open source it is auditable, and therefore more trustworthy than the endpoint machine.
Per the previous argument, this is irrelevant. If I assume the endpoint machine is compromised then I can put any number of well-intentioned boxes on my network and they won't improve the security of the user because the data was compromised before it ever left the endpoint.
Of course, you might argue that since the UnJailPi is open source it will not have vulnerabilities, that the risk of compromise is therefore 0, and that while that risk is added (per the previous argument) to the risk that the endpoint is compromised, it doesn't change the total risk in the system.
This is patently false. While I'm as big a fan of open source as you are likely to find, the reality is that vulnerabilities happen even in the best audited code. We've seen several nasty ones in open source projects this year alone, ranging from the futex bug in the linux kernel (CVE-2014-3153) to the heartbleed bug in openssl (CVE-2014-0160). You mention the security of OpenVPN: it has had two severe vulnerabilities this year (CVE-2014-5455 and CVE-2013-2692) and one additional one in the last 12 months (CVE-2013-2061) besides being vulnerable to heartbleed and early CCS (CVE-2014-0224).
This obviously doesn't mean that you shouldn't use open source code, or that you shouldn't use the projects in question! It does mean that you should limit the total amount of code which, if compromised, leads to the compromise of your security. By adding unnecessary and *very risky* components like PHP, not to mention the effectively unaudited code unique to this project, you are increasing the total amount of code which exposes you to risk, and therefore increasing the risk you are exposed to. In my view this risk is entirely avoidable.
Keys and Consequences
-----------------------------------
Your project page says you generate RSA-1024 keys. I hope that's a typo.
RSA-1024 is hilariously weak today. NIST (that bastion of trust and security...) has officially recommended that all 1024-bit RSA keys be end-of-lifed as of last December, meaning that they are no longer considered "good enough" for use in any product, even for legacy or compatibility reasons, and even in the absence of implementation errors. So when you advertise on your project page that you use RSA-1024, well, let's just say it doesn't fill one with confidence that all the other security decisions have been made appropriately.
Of course, the fact that your chosen algorithm is insecure in the absence of implementation errors does not imply that it lacks implementation errors. Happy to talk more about that if you're interested.
Bottom Line
-----------------
Honestly, there are a bunch of other issues I'd like to talk about here- the increased risk of physical attacks vis a vis devices like mobiles and chromebooks, the questionable utility of TOR, and the still very much closed source nature of critical parts of the raspberry pi- but I suspect I'm talking to a wall. I understand why this seems like a cool thing to build, but it doesn't improve anybody's security, and potentially does quite the opposite. I don't really expect you to agree with that at this point, but if you have any questions or interest in pursuing any of the things I've mentioned feel free to reach out to me- I'm happy to help.
Are you sure? yes | no