Thursday, August 7th, 2014

Two-factor laptop decryption using a smartphone

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.

Comment #1: Posted 4 months, 1 week ago by Anonymous

> I am currently looking for any feedback on this, and to see how much interest there might be for such as product.

Hello Kevin. I am going to answer to your feedback request. Reading the full post I reached a few conclusions and I am basing my response on them. Further information may change this conclusions but I tried to construct a response as constructive as possible with the information you are giving.

The laptop/smartphone pair concept is interesting. It is a logical step to follow considering the "something the user has" factor. But I believed the common smartphone is a complex piece of hardware with too many potential attack vectors. I think your system will be more secure if you use a specific piece of hardware with specific encryption features. In other words, I consider the smartphone itself a risk factor.

About the code availability, there is a lot of literature about the "encryption by obscurity" techniques. They are considered a bad approach to security. In general, any system who is not publicly auditable is considered insecure. The existence of a central infrastructure to guarantee security does not grant an exception to this "rule" but creates a single point of failure to exploit the system.

You posted an exhaustive plan to attack your system in the post. Is nice to try to think as an attacker to secure your system but if you are considering only that plan you are understimating the power of lateral thinking. The fact that you are exposing that plan as the only plan (quote: Let's review what a hacker will need to do) is telling me that you are overconfident about your system.

There is also another thing that raises my concerns about your idea. You are looking overprotective of your idea. You also are not using common terminology in cryptography, which tell me that you are a newbie in this field. Do not get me wrong, I am not saying that you are unqualified, but I need and strong crypto/math background to believe in someone who is saying: "I have this idea I am sure is really good but I can show it to you". Extraordinary claims require extraordinary proofs.

Then I draw two main conclusions from all the previous points: your system is not mature and you require an expert with a strong crypto/hacking background to audit and support you if you want to be considered by the serious cryptographers/hackers who work on auth. I personally do not know anyone who can help you but the best ones I know do not work with closed systems. They take this things very seriously.

Regards.

Comment #2: Posted 4 months, 1 week ago by Kevin Veroneau

@Anonymous

Your comment is a bit flawed, this is a not a new encryption technology. This is only used for the key generation portion, the key/passphrase required to decrypt. The actual encryption is still handled by the same old open source Cryptsetup, which can either use a LUKS header or not, depending on how you pipe this key generator into the encryption service. I also never ever stated that this will be a "closed source" project, so please do not put words into my mouth. If you read other articles in my blog, I tend to embrace open source, and most, if not all my projects I personally create are open sourced at one point or another in their lifetime.

Comment #3: Posted 4 months, 1 week ago by Anonymous

Hi Kevin.

I think you are right with the cryptographer point. I actually think that you need a really good hacker to back your project. I said a cryptohacker because they are used to this kind of problems, Also, because the way you mix the different key parts to create the final passphrase is also important. But you also need a more broad hacker perspective for the other points I stated.

About the open software, I know you have a lot of open software. And I am grateful to you for making it open. I was trying to say that before we (the community, potential backers, etc) can audit the project, we need access to the code if we want to have an idea about its value. In fact, I told you about finding a good hacker/cryptographer because if you can not provide the code before the crowdfunding, you will probably need someone to back your tech value. I assumed you were going to keep the code closed because of the sentence "I will not be releasing the source code for this project, so do not ask.".

But please. Do not take my comments as harsh criticism. I think your project is interesting and it may be a practical idea to increase security in some cases.

Regards.

About Me

My Photo
Names Kevin, hugely into UNIX technologies, not just Linux. I've dabbled with the demons, played with the Sun, and now with the Penguins.




Kevin Veroneau Consulting Services
Do you require the services of a Django contractor? Do you need both a website and hosting services? Perhaps I can help.

If you like what you read, please consider donating to help with hosting costs, and to fund future books to review.

Python Powered | © 2012-2014 Kevin Veroneau