This is a pet project I showed to a select few at PyCon 2014 in Montreal. I have not publicly disclosed this project to anybody else in the tech community until now. I will not be releasing the source code for this project, so do not ask. I am either planning on obtaining a patent for this, or starting a Kickstarter project to obtain the funding required to develop this into a full fledged product for multiple platforms. Currently it only works with Linux, as it was much easier to prototype using such an open and hackable operating system. However, given enough interest, I would love to port this product over to Mac OS X and Microsoft Windows platforms. I am currently looking for any feedback on this, and to see how much interest there might be for such as product.
This product has three separate parts, which enable what I am calling Chained passphrase decryption. The third part of the chain is not mentioned in this video, nor will I talk about it at all. Basically, all parts of the chain are required to successfully construct the final encryption key that will be used to decrypt the device in question. My software does not perform any actual encryption, my software only constructs the key which is then passed on to the encryption software. On the Linux platform seen in the video, the encryption software used is LUKS, which is standard in every Linux distribution for block level encryption. This software should theoretically be usable with any software that can accept a passphrase.
The main communication link as seen in this video is a standard authenticated bluetooth connection, from the smartphone to the laptop. The connection is only active for as long as it takes to obtain that part of the chain to construct the final passphrase. In most cases, the software is manually launched by the consumer when he or she needs to decrypt his or her device. On most secure smartphones, the consumer first needs to unlock their device with a password, PIN, or fingerprint in order to launch an application on said device. Most devices also support full encryption, securing this solution even further. With only these two chains being mentioned, there is a lot of work a hacker will need to do in order to obtain the encryption key to unlock the device. Let's review what a hacker will need to do:
- The hacker will need physical access to both the laptop and smartphone
- If the hacker only has the laptop, he or she can try to bruteforce the encryption, however since the actual key is a binary format, and can be very long. This might take the hacker a very long time to crack. This key isn't your everyday ASCII passphrase, which are relatively easy to crack since the human alphabet is limited.
- If the hacker has both the laptop and smartphone, they need to unlock that smartphone using the smartphones authentication. The only way by this is to remove the NAND chip(and hope that it's not encrypted), or find a vulnerability in the smartphone's lock screen.
- If the hacker finally has access to the devices data and can run the application which creates the bluetooth link. The hacker then is required to enter in the correct PIN on the device. This can be brute forced, but hopefully the hacker never gets to this point.
- Finally, there is one last part of the chain, the third part, which can break the chain of trust entirely, preventing that smartphone and laptop pair from even working. I will leave this part to the imagination of the reader.
As you can see, much thought has been put into this product to make a more secure laptop for consumers and corporate workers. Unlike existing solutions which rely on local-only measures to enforce encryption, this method takes it a step further to authenticate the end-user in question using their most personal device, their smartphone. In this day and age, everybody has a smartphone, or if you work for any large company and have a company laptop, you most likely carry a company smartphone with you at all times. So naturally, the next step of laptop encryption should use this pairing to harden laptop encryption.
UPDATE 08/08/2014: I have been receiving various comments from the different sources which I posted a link to this. I would like to clarify that this project may or may not be open source, this variable has yet to be determined, thus is why I am not releasing the source code at this time. Some comments are pointing on the fact that bluetooth is insecure, well this might be true, so is plain text SMTP, HTTP, etc... That is why you place an encryption layer over top. For email, this is normally PGP encryption, and for HTTP, this is SSL. This bluetooth link is also encrypted, currently using AES, but this is subject to change. AES was mentioned in the original video. Hopefully that clarifies some additional left out details.