This project is submitted for

Description

Recent and ongoing disclosures show that our individual privacy has been severely eroded and that we should only expect that trend to continue into the future. While sitting around the common table at Sector67, a group of us recently discussed the idea of this project to protect privacy. The Hackaday Prize provides us a great incentive for us to get working on it now. Any prize proceeds would be donated to Sector67, a 501(c)(3) not for profit corporation in Madison, WI.

Our goal is to create an open source solution that facilitates private communication while being simple and verifiable to the end users. Our initial implementation provides a practical and useful solution that facilitates more secure communication and provides a platform for future investigations.

Details

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.

2×
MicroUSB connector
Plugs in to a computer to charge, or to act as a HID keyboard, putting random numbers out .

1×
Android v4 capable device
For the prototype, we are running the message entry, message reading, encryption, decryption, OCR and keystroke sending using an Android device. This device should be capable of running Android v4.x and ideally have a camera, USB port and external SD card reader

We celebrated our semifinal submission milestone at code jam #8, and managed to get a few features (most significantly serial sending for the USB/HID bridge) and defect fixes merged upstream and tested as well. We're hoping we've gotten every i dotted and t crossed!

Video code jam #7 wrapped up last night with a flurry of productive activity. We shot the raw footage we need to edit into the five minute video and worked through a few last-minute integration issues with the USB OTG support and OCR. There are still plenty of small development tasks, but we are sending messages device-to-device using keys from the hardware generator. Expect some code cleanup over the next week as well as some additional documentation!

Random Number
Generator

I know it's not funny, but the only
thing that's NOT working is the hardware random number generator. It
turns out my analog-fu and ability to read documentation is lacking.
While the current circuit does generate random noise, it's in a very
narrow range (20mV peak to peak), and at a random voltage about 1V. I
can't do much with it without some amplification and craziness. At
least, it'll require a new PCB or some breadboarding with parts I
don't have yet. The good news is that I can use the Arduino pseudo
RNG TEMPORARILY as a stub
until I get real random number generation working. I believe this is
completely fair, as I can't have this holding up the rest of the
development, and I do have prototypes that show some
randomness coming out of my RNG circuit, just not good enough for
digital conversion.

New Part

We had a discussion about how to
get the data from the Android device to the computer. One option was
having the Android device flash light, which a photodiode would
detect. This turned out to be too slow for reasonable data
transmission. We didn't want anything wireless, as that would cancel
out the idea of the Android having all wireless completely disabled.
We decided to go with USB OTG. But instead of the Android connecting
to the computer directly, we wanted it to go through our trusted
device. This way only one thing plugs in to the computer. To do this
we added an FTDI chip; the FT231RS, which can do USB OTG to serial.

The serial was then piped into
the hardware, and a new firmware mode was added to allow data coming
in from the serial to be sent out through the other USB port
connected to the computer as a keyboard. This way we can guarantee
that no drivers are needed on the computer, and that it will only
ever interface as a keyboard to anything; ensuring that data can't
flow backwards into our secure device.

Implementing was a little
challenging as I'm essentially out of available pins, and I think
there is a conflict with one of the other libraries that prevented
SoftwareSerial from working. I eventually rerouted some wires and got
Serial1 working, but it was a tough half a day.

Everything Else
Hardware

Everything else is working well.
There was a small change necessary on the hardware to get the write
protect detection working on the SD cards. Now the firmware can check
on the card presence and the write protect tab to make sure that the
cards are present and writable before doing anything.

The enclosure has been updated
as well. It's a little prettier, smoother, curvier, and now black!

Firmware

Using the newest version of the
SDFatLib (https://github.com/greiman/SdFat)
was a breakthrough. It has support for two cards at once, so I didn't
need to rewrite the older SD library. Most of the features are now
working completely, and the ones that aren't are not on the critical
path for the minimum viable product. In other words, all the stuff
that has to work does, and the rest is just nice to have.

We are working furiously toward the final working prototype, with the goal being to get all the necessary footage next Sunday to edit into the 5 minute video. Significant progress made includes getting each team member on a critical task: OCR integration, USB sending, HID bridge, hardware key generator and video sketch.

We had lots of good discussion and made several critical decisions to prioritize and prepare for the push toward Sept 28. Most notably is a plan to implement the capability for the hardware encryption device to read encrypted data via light flashes from a screen (both a PC and Android device) and forward the resulting data as keystrokes via HID to either a PC or Android device. This allows us an alternate data path for both OCR and USB keystroke sending from Android and greatly increases the number of potentially compatible Android devices. We'll still be fully implementing OCR functionality, and will maintain the light/HID as a parallel approach for transmitting encrypted data to the Android device.

It's been a while since the last log,
so hopefully this one will make up for it. We've got good progress to
report.

It works!

Here's a video of the device generating 1KB of random data and outputting it as HEX characters over the USB keyboard to a text editor.

Code

There are lots of parts to the hardware, so I wrote test
applications for each section. Some parts don't have code (like the
battery charger), but everything else has its own small sketch to
test the individual section. The current list of test sketches:

Buttons_Test – tests the four buttons, AND tests presence
of each SD card and the write protect of the SD card.

SD_Test – uses the SD Library to access the SD cards one at
at time.

LCD_Test – tests the LCD library with a hello world.

Random_Test – tests the random number generator hardware
and the shift register for bringing the data in.

USB_Keyboard_Test – makes sure that the Arduino can talk to
the computer as a HID Keyboard. It needs to be one way so that the
computer cannot compromise the encryption device.

I've been putting it all together into the final sketch, though,
and have made a lot of progress. There's a functional UI which
responds to button presses. It connects to a computer as a USB
keyboard and when the user tells it, will spit out random numbers to
the keyboard.

Currently the random number generator part of the circuit isn't
working, so for now I'm using a temporary solution with the Arduino
pseudo-random number generator. In V2 of the hardware hopefully it
will be fixed and I can go back to the hardware RNG.

I'm also having a hard time with the SD cards. It turns out the
Arduino SD library creates globals that prevent me from initializing
two SD cards at once. Now I'm delving deep into the library code to
try to create and manipulate the two SD cards without using the
global. It's a pain.

Also, I realized there's no photo of the random number generator circuit underneath the LCD, so here it is. Note that the 8 headers can be used to create your own RNG circuit, or as a debug header to look at the random signal.

Case

The case is designed, 3D printed, and
fit on the first try. Well, there were some tolerance issues, but
some sanding was all that was needed for it to fit. It will be a two
part mold, with a parting line along the holes for the switch, USB,
and SD cards. That way it'll be a simple injection mold with no
slides and easy assembly, that's also easy to 3D print. Of course,
this is the first version, and as such is way bigger than it needs to
be and not pretty, so for the first case, I went a little overboard.
But it works and will get us moving along for the video and
demonstrations.

We've completed code jams #3 and #4 with the result being the first successful test of the encryption functionality across multiple devices with manual data entry. This makes the Android program useful on its own, but we are continuing to work to integrate the OCR and keystroke sending features.

In the last post about the hardware, I had 3 items that weren't working as expected. I'm happy to say 1.5 of them are solved, and they ended up being soldering problems, mostly caused by the stupid QFN package of the ATMEGA32U4. Unfortunately, the TQFP package is in high demand and unavailable everywhere, so I've had to use the QFN package lately, which is a pain to solder.

Anyway, the first problem, the left SD card, is now solved after reworking my soldering. I also populated a second board and it also works, so I'm relieved about that.

The second problem is the LCD, and for that I'm halfway to a solution. The problem is that I'm using 3.3V everywhere, but a 5V LCD. A bit of a pain, and it's possible that it could have worked anyway, so it was worth a shot. I played with some different resistor configurations for the contrast and found that the LCD is indeed working, though the contrast is so low I can barely read it. I have new 3.3V LCDs coming in a couple days, so hopefully that will work. But the code is correct and the LCD does initialize and show 'hello, world' so at least we're somewhere.

Still need to figure out what's wrong with the random number generator circuit.

This is a great project but it must clearly get the phone out of the equation. Its to many additional vulnerabilities for OCR not counting remote compromise especially base-band that can never be secured. Look into the following http://hackaday.io/project/1313-openmv or Arduino based items that could handle the OCR end.

I have made an Excel spreadsheet that automates use of two text sources (could be Project Gutenberg books, EULAs, etc.) to make a OTP. The method is this: First, clean the text from two sources of all non-alphabetic characters and spaces. Then look up the first letter of the first source in the second source and note its position. Look for that position in the first source and note the character. Attention is made to occurrences of letters so that no pairing is ever reused. I then use the same process but switch which source is first and second. Now we have two very long strings. (I also then reverse a string and do the same look-up/correlation again on these two strings, for extra complexity, though this is not essential.) Then for each character value of my clear text (to be encoded) I add it to each character value of each pad, mod26. This gives me two versions to choose from of encrypted text. I then send it through an analysis routine that counts the occurrences of each character and determines how many of each character to add in order to make the final result frequency-neutral (homophonetic). (I also use a separate routine to pattern scatter the homophonetic characters throughout the code.) This results in having the exact same number of x's and z's in your code as you have of e's and t's, and is perfectly indecipherable.

My decryption process is to remove the homophonetic characters first, then take two passes at decryption using the same look-up/correlation process I used before, which will result in one string of garbage and the other string will be the original clear text message.

Now, all that needs to be communicated to your recipient is the two sources to use, and optionally, what pattern to scatter inject the homophonetic characters.

Our ultimate goal per this contest is an integrated key management and encryption/decryption device, which would not have wireless capability, so that would mitigate that risk. We are working on a USB serial solution that would basically provide similar assurances to the data diode approach while still remaining a HID device. You'd have to have some trust in that adapter or build it yourself.

Your shipping interdiction concern is also a valid one, and all the specs will be open to maintain a DIY option. In fact that will most likely be the primary way to obtain a device.

Our current implementation overwrites keys after the message has been read or sent, allowing a brief period of re-reading or re-sending in case there are problems. However, you can't leave the "view plaintext message" screen or "send encrypted message" screen without the keys getting overwritten. The key media is definitely a concern as well, even if overwriting is done.

I'll add a project tasks for message padding and disabling logging by default.

Also thanks for your work on Tin Foil Chat. We did extensive searching before getting started and didn't come across your project, but you are right the overlap is significant. Your documentation on the concept and implementation are both fantastic and if you're interested in collaborating we are as well.

jpixton the one time pad is the only proven unbreakable cipher as long as the key material stays protected. Theres plenty of projects utilizing public key infrastructures which will work great until quantum computers or new vulnerabilities are available. One Time Pad does not have these issues.

* It fails catastrophically. Under failure, it has no deniability or confidentiality. If you've lost confidentiality, then deniability is a good property to have.
* Your screenshot with a ciphertext and plaintext pair does not seem to have a enough ciphertext expansion to have any authenticity. Does it? If not, what stops $BOOGEYMAN changing your message "I will pay you $100" to "I will pay you $999" by flipping bits in your message in transit?

We have *much* better mainstream crypto than one time pad these days, and you can even entirely avoid NSA influence if you desire.

Thanks for the feedback. The screen shot was a mock up. Message authentication can easily be added, and we do plan do that (although not as a priority initially). Of course that can not stop someone from flipping bits in transit but it will detect that it has happened. What currently stops your scenario is them not knowing which bits to flip.

I'm interested to understand more details about your opinion that OTP fails catastrophically and what you would specifically recommend as much better. It seems to me that the main weakness of OTP is if key management is not done properly and all crypto systems suffer that same weakness, with the same catastrophic failure. Keep in mind with a deniable crypto system you would be intentionally giving a false key, but if the real keys are compromised (the same weakness I presume you are saying makes OTP fail catastrophically, but please correct me if I am wrong), then you do not have deniability.

One of our important goals is to have a human-verifiable system, and that is a significant advantage of OTP.

I'm also interested to understand specifically how you would avoid NSA influence but use a mainstream crypto system other than OTP. Given what we know about NSA involvement in crypto system development, those two goals seem mutually exclusive.

In the future it is likely, due to hardware, math and other advancements, that many if not all algorithm-based crypto systems will be readily breakable (see DES for example). Even if using currently deniable crypto systems your messages will be retrospectively vulnerable. To me that seems like a significant problem.

I'm somewhat confused...
There is talk about a one time pad, but it seems that this is re-used?

Then in these comments it seems that a really long pad is generated, and stored on both cards, then thrown away as used.

So if the OTP is 1324534675689780 and a four letter word is sent then the OTP on the senders card becomes.

534675689780.

When the recipient reads that message their used OTP section is also part destroyed.

Cool so far...

What if the message is lost in transit, never delivered, and needs to be re-generated/resent?
or if one email is delayed in a resend queue whilst another is not. then messages are delivered out of order? -and can never be decrypted?

Now the OTP situation looks like this
sender :1324534675689780
send four letter message

In the encrypted text that is sent is also sent the offset to use. So you start with 1324534675689780, send a four letter message like "0,XXXX", and the sender's OTP now looks like 0000534675689780. The used OTP section is destroyed, so if the sender's pad was compromised old messages couldn't be decrypted. Now the sender sends another four letters, and the message would be 4,YYYY, indicating that the message should use the 4th character as the offset for the message. So the recipient gets the second message only, and they see 4,YYYY and their pad looks like 1324534675689780. Now not only can they decrypt the second message properly, but they also know that they didn't get a message. After decrypting, they end up with 1324000075689780 (or 0000000075689780 depending on implementation).

Your next question is what happens if they send messages at the same time? It screws with the offseting and the zeroing. But not if they use different directions. So person A starts at the beginning of the file and goes from 0 up, and person B starts at the end of the file and decrements. Eventually they collide somewhere in the middle of the file, and then it's time for a new OTP.

To add to what Bob says, the safest is to use two different pads, one for sending from Bob to Alice and one for sending from Alice to Bob. Then there is no possibility that the same pad would inadvertently be re-used, weakening the encryption and also (with re-writing of the used keys with new randomness or zeros) making the messages unreadable.

Very cool idea. Please consider utilizing full disk encryption on the storage cards utilizing AES 256 in case the card was lost or stolen. The problem is since there is no way to securely delete non magnetic storage it will have to stay encrypted. Maybe add the possibility of connecting a keyboard directly to the device to type the password so the pc never gets it?

Excellent feedback, thanks! Data is always entered on the device directly (even for instance if we added key encryption), so the password would never be exposed to the PC. Perhaps I'm not understanding your concern?

Hello Scott and NSA Away team. It doesn't look like you've updated your project in the last couple of weeks. Now is the time to add a few more details to give it the best chance of going through to the next round of The Hackaday Prize.

By August 20th you must have the following info on your project page:
- A video. It should be less than 2 minutes long describing your project. Put it on YouTube (or Youku), and add a link to it on your project page. This is done by editing your project (edit link is at the top of your project page) and adding it as an "External Link"
- At least 4 Project Logs
- A system design document
- Links to code repositories, and remember to mention any licenses or permissions needed for your project. For example, if you are using software libraries you need to document that information.

You should also try to highlight how your project is 'Connected' and 'Open' in the details and video.

Nice project. In order to skip the OCR step (if the message length is not very long) you can use some form of 2D encoding [QR code] on the receiving end to allow the arduino device to read the message. Or, you can paste the text into an editor, change the font into "code 39" (there are several fonts that implement this 1D bar code) and read it with the arduino camera. I suppose that this could be done with a optical mouse sensor.

Interesting ideas. We've focused on the least common denominator for now with OCR, but the feasible message length with that will probably be less than even with a QR code (although we could get creative with panoramic mode or something like that). There are lots of great things about QR codes (error correcting, parsing libraries, etc.), but for our purposes it does suffer from the lack of being able to be easily verified by a human. I can easily see some sort of bar code encoding as a future extension though.

It doesn't matter if you cannot read the qr code without a decoder. It's just another link in the path of the message between two devices. If the message is corrupted, not by human reading will see that but by checks done on the device (i suppose that you will encode a check sum). A phone with camera can show you the content of the qr code if you wanna read it, but the message is certified as genuine only when read from the device.
QR standard allows you to break a message into up to 16 sub messages each with his own qr code, and you'll need all of them to get the original info. This also could help by sending the message through several channels (email accounts, blogs, webpages, so on). This feature is called "structured append".

Not being able to human-verify the QR code does matter to a small degree in that (for our "ultra-paranoid" use cases) you want to make sure the device has sent your encrypted message and only your encrypted message, no additional metadata. Sending a QR code makes that much more difficult to verify. Watching simulated keystrokes allows you to do that.

Not really my speciality but you can also use any common shared digital for a one time pad, eg a CD, a picture on facebook or even a streaming radio station? Spies used to use pages from books I believe to encode messages which might be easier than taking something with you.

You are right that things like books can be used as a shared key. However, for a secure one-time pad, the randomness of the key data is very important (http://en.wikipedia.org/wiki/One-time_pad#True_randomness). The types of data in books, music, images, etc. are not very random at all, and so would not make a good one-time pad key.

This is a cool idea, I'd really like to see done with one device though. Preferably skipping the android phone and using something like OpenMV (http://hackaday.io/project/1313-OpenMV) for text recognition. Directly driving a touch screen from any number of Arduino compatible processors is a fairly straight forward task these days and could provide a great UI. It also opens modifying the interface/adding features to anyone familiar to the Arduino environment as opposed to needing to know how to build Android apps.

For right now the Android platform makes a great prototyping platform. The team has talked through lots of possible "version 2" options, both in the direction of less things you need to trust (e.g. a simpler platform like what you describe), and in the direction of less paranoia (e.g. a phone app or using GPG keys). There are lots of options, but right now we're focusing on Android to prove the concept.

There is a hardware component that is separate from the Android component. We have an ultimate goal of a single device but are making a proof of concept using two separate platforms and splitting up the labor. The hardware component currently in development has an LCD, 4 buttons, 2 SD card slots, a USB HID Keyboard, and a RNG circuit, all built around an Arduino. Eventually it'll get the camera and ability to do it all on one device, but not yet.

Currently, you're relying on the HID drivers to be secure and uncompromized. If you turn the paranoia dial to 12 :), there's no reason why the HID driver couldn't do something malicious, like rewriting code or corrupting messages. I can't think of a way to completely separate the computer and encryption device though, any thoughts?

@ArchimedesPi, very good thought. The threat model for the encryption device definitely includes malicious HID drivers on the target computer. People have gotten Android devices to work directly as a HID device with kernel modifications (http://forum.xda-developers.com/showthread.php?t=1871281 and https://github.com/pelya/android-keyboard-gadget), which leaves this channel of attack open. However (and to be fair we have not really documented this on the page, only discussed it in our group meetings), to really mitigate the threat of a malicious target computer HID driver a hardware adapter (USB on the Android side to simple USB HID on the PC side) would be needed that eliminates the possibility of any HID attack propagating to the encryption device. We do plan to make a prototype device like this as a part of this project, but it has not been at the top of the priority list yet.

In terms of the HID driver rewriting or corrupting messages, the goal is to keep everything human-verifiable, so that you could directly compare the encrypted message displayed on the device with the keystrokes displayed on the target computer's screen. In theory you could implement a feature re-OCR and verify it before clearing the key used, but we are not implementing that in the prototype.

The attack vector in the other direction is definitely feasible as well and has been demonstrated (compromised Android device attacking the PC). The goal of only attaching to send the keystrokes (and perhaps having the USB HID adapter not able to send any sort of characters outside of printable ASCII) does also mitigate that to some degree, but deserves further thought.

Great project Sector67! Thanks for entering The Hackaday Prize! This is a great idea for keeping short communications secure. How capable are android devices at doing OCR without the help of Google on the back end?

That question has been one of the major technical risks we've been working to iron out. We are using Tesseract, a native open source OCR framework that will run on Android, in a unit test environment to test various configurations. Indications are that it will be basically workable, providing we do several things, including encoding the encrypted message into hexadecimal, separating each byte into its own "word" and constraining Tesseract to only look for hexadecimal characters and those two-character words.

In our unit test environment, adding additional error correcting information allowed for 100% recognition, but the error correction information comes at a cost of not being readily human-verifiable. If you want to check out our Andriod unit test environment, instructions for getting started can be found here:

You say that your smartphone can be exploited. Which I completely agree with. Your computer is also easily exploitable. I don't see how this is secure... forgive me if I am wrong. Only in a perfect world trust is kept. What if someone steals one of the cards created and the person with the other card is unaware? Another cool addon would be to convert the message into a picture which has the last 2 bits of the color channel encrypted with the encrypted pad (stenography). Anyways I really like your project guys. Keep it up!

The only time your communications are unencrypted is when they are displayed in the device. When you want to send an encrypted message, you type it with the device- and it acts as a keyboard, typing your encrypted message. Therefore, any time data is in your computer is when it's encrypted.

You're right, if someone stole the card, they'd be able to decrypt old messages. When the device has matured past the initial Android proof-of-concept, and on to a simpler, hand-built device, we will look at securely destroying old data.

You could encrypt the encryption with a key, but it would add complexity, and doesn't fully solve the problem. A key may be cracked, given enough time and resources. A properly implemented one-time pad may not.

Physical access to the device by wrong doers means nearly all bets are off for security. One has to keep their encryption device locked up or in hand at all times.
The best feature of OTP is that you can and should change keys often.

@visualkev: When you encrypt or decrypt a message, the part of the key used is deleted after it's done encrypting/decrypting the message. That means there's perfect forward secrecy too, so after you decrypt/encrypt a message, *no one* can *EVER* get it back - the key's gone on *both cards*.

@visualkev: The data is stored on an SD card, so physical access to the device without the SD card isn't a problem. In addition, you can write as big or small an OTP as you want, so if you and the person with whom you are communicating can exchange OTPs often, then you could get away with smaller OTPs. If a long period, then a larger OTP can be generated.