NSA Away Hackaday Prize Criteria
Our five minute semifinal video
How “Open” is the design?
NSA Away is designed to be both open source software and open source hardware. This is not just because it is a good thing to do. Since trust of the device is a fundamental requirement, the open nature of the design and implementation are critical to its functionality. This device could not succeed if it was either closed hardware or software. Because openness is a fundamental requirement, this makes it an excellent showcase for the open source hardware and software movement and highlights the need for programs like the Hackaday prize to provide incentives for devices like the NSA Away to be developed.
“Wow” factor: is the entry innovative, is the build impressive?
The concept of unbreakable one-time-pad encryption was first proposed in 1882, but it has been unwieldy and impractical for regular people to use it until now. This ambitious project required extensive hardware and software development. We have interfaced multiple devices in a user-friendly and convenient way.
Specifically, we designed and implemented a true hardware random number generator that saves the same random key to two SD cards and designed and 3D printed the case to protect this new device. We wrote user-friendly software for the android phone to read the SD card and encrypt the message the user types in. We went through several design iterations before settling on a reliable yet secure way to send the information from the encryption device to the laptop. We wrote and integrated software to interface with Google’s open source Tesseract optical character recognition engine to provide on-device OCR so that the receiving person can decode the message easily.
Is the entry a connected device and is that “connectedness” meaningful to the function?
The function of the NSA Away is to allow friends and colleagues to connect safely and privately. Improving social connectedness via technical connectedness is the absolute purpose of the device. By being connected yet separated in very specific technical ways, the NSA Away solution allows two individuals to maintain the privacy of their communications even if they do not trust their own PCs or the network connections between them.
Is the project reproducible and could the work be extended for other uses?
We have designed and implemented the solution in an open way, so anyone could use our design and implementation to reproduce their own NSA Away devices. The concepts and work behind the NSA Away project could be extended in several different innovative ways. Our solution as implemented provides human verifiability to all steps of the process and keeps the encryption keys and message composing/viewing device isolated from any Internet-connected infrastructure. If those are not hard requirements, a range of other extended applications are possible, including:
- Use of asymmetric key algorithms (GPG, etc) so that key pre-sharing is not required.
- Running the encryption/decryption applications on a non-dedicated smart phone or tablet device, directly integrated with the device's chat and email functions or other custom applications. For instance, using the NSA Away project as a base it is easy to imagine an open source snapchat-type application with pre-shared keys and true forward secrecy.
- Using the keystroke sending functionality of the encryption device as a password manager.
- Using the key generation device as a verifiable USB-connected hardware random generator.
- Integrating a cellular or other wireless connection for message sending and receiving, providing an extremely secure pager-class device.
Of course most of those applications compromise privacy or verifiability in one way or another for increased convenience, but all of them would increase privacy, make strong crypto more mainstream and decrease the effectiveness of bulk surveillance.
Does the entry exhibit engineering innovation?
Although excellent projects like Tin Foil Chat exist, there are currently no mainstream solutions to facilitate one-time-pad encryption. If ready-to-use devices do exist, they are not freely available to the public. The integration of on-device OCR represents, as far as we know, an innovative and novel approach to maintaining a verifiable no-compromise encrypted message reading interface. We believe use of a one-way USB HID interface for sending encrypted keystrokes is similarly innovative.
The convergence of several trends, including high capacity portable SD card data storage, high-resolution mobile cameras, increased mobile computing power and improvements in open source OCR frameworks have only recently provided the opportunity for solutions like the NSA Away to exist.
Is there an intuitive interface? (is the entry usable in the real world?)
Both the random number generator and the encryption device were developed with ease of use in mind. Users will recognize the encryption device's application interface as being familiar to other smart phone/tablet programs they have used. We have used NSA Away to transmit secure messages in the real world.
Is it/could it be manufacturable?
The NSA Away concept could be manufactured in several different forms.
- As an assemble-your-self key generator kit for electronics enthusiasts (provide your own old android phone)
- As a ready-to-go random number generator device and downloadable app for a phone or tablet.
- As an integrated encryption device and hardware key generator including camera, SD card readers, soft or hard keyboard and one-way keystroke sending capability designed to be used with a separate PC.
- As a completely self-contained three-in-one emailing/texting device. A cellular or other wireless transport would be integrated on-device, making use simple and removing the requirement for a PC.
The implementation consists of two devices:
1) A simple, standalone key generator that generates random key data and writes it to two SD cards simultaneously, thus creating two identical one-time use pads for encrypting future messages. This hardware random number generator can generate random data for other purposes and send it via a USB port.
Schematics for this device and a bill of materials are provided in the project links.
2) An Android-based encryption device with a camera, display, software keyboard, SD card reader and USB port. All other methods of communication to the device (WiFi, Bluetooth, IR, etc..) are disabled at the hardware level. This standalone device encrypts and decrypts messages. Incoming encrypted data is read from your PC’s screen via the device’s camera, and with on-device software optical character recognition (OCR) is converted and decrypted using an SD card-stored key. The decrypted message is displayed on the encryption device display. Using a camera to capture the encrypted text from the PC display prevents the PC from retransmitting anything but the encrypted message which is not decryptable by anyone not holding the one-time pad key. The used portions of the keys are erased on both the sending and receiving ends after use to provide forward secrecy (your message cannot be read by someone later even if they obtain your device).
Our prototype encryption device is implemented using an Android tablet or phone. Requires specs for the Android device are listed in the components section. The source code repositories for the Android application are referenced in the links for this project and are hosted on github (see project links). They are licensed using GPL 3+. We use several additional open source libraries to provide the complete solution, including Apache Commons Codec and Commons Core (Apache License 2.0) and Tesseract OCR (Apache License 2.0).
Messages to be encrypted are entered by typing on the encryption device's software keyboard and then encrypted using a one-time pad cipher with keys stored on SD cards. The encrypted data is sent off-device by having the encryption device act as a USB HID keyboard on a regular PC and sending simulated keystrokes. The encrypted data is encoded in a simple text format that is human-verifiable. This interface style prevents the encryption device from transmitting any data off the device outside of the HID compliant driver. The video below introduces the team and describes the usage in more detail:
Before needing to send a private message:
- Use the dedicated hardware key generator to populate two SD cards with identical one-time pad keys
- Keep one copy of the key for your self and give the other copy to the message recipient
To send a message:
- Type a message on the encryption device using the software keyboard
- Choose the appropriate encryption key from an SD card to encrypt the message. You would choose a key that you pre-exchanged with the message recipient.
- The encryption device encrypts the message using that key
- Start composing an email to the message recipient on your PC and have the cursor active in the message compose window
- Plug in the encryption device via USB and click send to have the encrypted message typed into your email. Your encrypted message will be typed into your email message by the encryption device sending keystrokes.
- Send the email on the PC
To receive a message:
- Open the email containing the encrypted message on your PC
- Point the encryption device’s camera at the encrypted message and take a picture of the encrypted message
- The encryption device performs optical character recognition (OCR) and interprets the data
- Choose an appropriate key from an SD card to decrypt the message. You would choose a key that you pre-exchanged with the message sender.
- The encryption device decrypts the message using that key
- You read the message displayed on the encryption device’s screen
As long as key exchange and management is done properly and the Android device remains physically secure this solution should provide very private and secure message transmission. The portion of the key used for encrypting or decrypting the message are deleted after use, thus also providing forward secrecy: the unencrypted message cannot be recovered from either the sender or the receiver once it is sent and read.
Frequently asked questions
What's up with the application icon?
The application icon is an an XOR logic symbol. The simple and human-verifiable XOR operation is the basis of one-time pad encryption. It is designed to evoke both a spaceship in the spirit of the Hackaday Prize and an air-gapped connected device.
Why use a one-time pad algorithm for the encryption?
There are several factors that make one-time pad (OTP) encryption appealing for this project. Firstly, the algorithm itself is relatively simple and verifiable does not require you put your trust in advanced mathematics. That is by far the most significant factor.
OTP certainly introduces significant key management challenges. However, now that we can store significant amounts of digital data cheaply and portably via SD cards, some of those challenges are simplified. The key generation hardware that is a part of this project also addresses some of the concerns around secure key generation.
The use of OTP necessarily limits the applicability of the prototype to situations where you can pre-share keys. Beyond the prototype, additional ciphers could certainly be implemented, even using the same SD card storage solution for key management. However, our initial implementation is focusing on OTP.
Your paranoia dial seems to be stuck at 11. Who would need to use such a device?
The basic use case is for anyone that wants to maximize the privacy and security of short message communication. This includes journalists, citizen reporters, human rights activists and others, but is not limited to them. As Bruce Schneier says, "Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect".
Why not just use your smart phone?
A phone would make a good hardware platform, but smart phones are readily exploitable and hard to verify. If that doesn't matter as much to you, you could use a smart phone.
But aren’t Android devices rooted by the NSA, etc?
Very likely yes, and in the long run a different, simpler platform would be better. However, the device is designed to only transmit and receive data in a human-verifiable way, and to otherwise be disconnected. This means that in theory if you maintain physical security of the device and SD card keys (a necessity for security in any case), even if the device is compromised you can confirm it is doing the correct thing, and it cannot send additional data “out of band”.
If I'm not doing anything wrong, why would I need private communication?
Bruce Schneier explains it better than we ever could: https://www.schneier.com/blog/archives/2006/05/the_value_of_pr.html
Why not use QR codes to send and receive the encrypted data?
QR codes would have several distinct advantages. They are meant for machine parsing and already include error correction. This capability should probably be incorporated eventually as an option. They could be used for incoming encrypted data by reading them with the camera, and they could be used for outgoing data by presenting
However, for our initial prototype, QR codes have one distinct disadvantage: they are not easily verifiable by a human. As a result, they are not a part of our initial prototype goals.
But I can only send as much information as my pre-shared keys?
This is true, but SD card key storage allows you to pre-share significant amounts of data. This solution is designed for private exchange of simple messages. You can fit a lot of simple messages in one gigabyte, and much larger SD cards are readily available.
What about using modulated sound to send the encrypted data?
This is another good idea and one that could eventually be incorporated for direct device-to-device communication. However, it also suffers from the problem of not being readily human-verifiable.
Wouldn’t this device make a good secure password store?
Since the device can simulate key strokes, it would probably make a good disconnected password manager, but that is not a part of our initial prototype implementation.
What if I am both sending and receiving messages with a remote party. Should I use the same key?
To avoid accidentally re-using the same part of the same key twice (which weakens the encryption), you should keep two separate keys for that remote party, one dedicated to sending messages and one dedicated to receiving messages.
But my PC is also easily compromised. How does this solution keep my data secure in that case?
The unencrypted messages are only ever available in a decrypted form on the encryption device. Even if your PC is compromised, only the encrypted content is ever accessible from the PC. Who you communicate with, how often and how much information you communicate would be able to be determined, but not the actual information in the message itself. The solution is designed to be defensive against a compromised PC by only allowing incoming and outgoing information flow to happen in an observable verifiable manner.
What's with the NSA Away name?
NSA Away stands for "No Snooping Around - All Words Are Yours"
What if someone steals one of the cards created and the person with the other card is unaware?
If physical security of the device and all copies of the pre-shared keys is not maintained, the solution is not secure or private. We do not believe there are any digital privacy or security solutions that work if physical security is compromised.
Doesn't key re-use reduce the strength of one-time pad encryption? Will you re-use keys?
Re-use of the same key significantly reduces the strength of the encryption [http://en.wikipedia.org/wiki/One-time_pad#True_randomness]. The system will be designed to not re-use keys, by keeping track of how much of the key has been already used, and by allowing the ability to clear key data as it is used for encryption or decryption. The true randomness requirement documented in the link above also underscores the need for our secure hardware key generator.
Should I use this for real world applications now?
This is currently a work in progress and not yet ready for real-world applications.
Why not use an asymmetric key algorithm instead. You would avoid all of the key exchange issues!
It is true that an asymmetric (public/private key) encryption algorithm would avoid issues with key exchange. However, our goal is to have a system that is as simple, trustworthy and human verifiable as possible. Public/private ciphers require you to put your trust in both the mathematical security of the algorithm and the specific implementation. The actual encryption and decryption operations are also much harder to human-verify.