Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

NSA Away

Increase your privacy and security by exchanging short messages securely. Created by members of hackerspace Sector67.

8.4k 41 138 119

This project was created on 06/23/2014 and last updated 20 days ago.

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.

Does the entry exhibit engineering innovation?

Although excellent projects like Tin Foil...

Read more »

Components
  • 1 × 16x2 LCD 3.3V Display for the hardware device
  • 1 × Atmel ATMEGA32U4 Microcontroller that runs the hardware device. Should have Arduino bootloader on it.
  • 2 × SD Card Holder 2 SD card holders allow for making 2 sets of identical SD cards at once.
  • 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
  • 1 × FT231XS-U FTDI chip converts USB to Serial, used as a serial port to allow the android device to connect securely to the computer through the NSA Away hardware
  • 12 × NPN Transistor (MMDT3904) Used for the reverse bias avalanche circuit to do the hardware RNG. This is a dual transistor package. 24 transistors are needed for 8 circuits.
  • 1 × MAX1555 Used for the charge management of the battery
  • 1 × MIC5205-3.3V Voltage regulator. Gives 3.3V for the whole system.
  • 1 × 74LS165D - Parallel in shift register Used to latch the 8 bits of the RNG and then shift them into the microcontroller.

See all components

Project logs
  • Build testing link

    20 days ago • 0 comments

    If you're interested to build and test the encryption/decryption device software, build instructions are available at https://github.com/Sector67/nsa-away/blob/master/README.md

    Any feedback you can provide is welcome!

  • Code Jam #8, milestone celebration!

    a month ago • 0 comments

    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

    a month ago • 0 comments

    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!

View all 19 project logs

Discussions

Markus Ottela wrote 2 months ago null point

Interesting. I like how every project that addresses end-point security comes close to one another. I would argue unless you can remove the hardware for wireless connectivity, you can't have certainty it's not leaking the keys, disabling them won't be enough. The OCR+camera should be secure enough but makes real time conversation somewhat tedious. For email purposes this should be convenient.

The main issue is the direct connection of TCB to the network connected computer. You can't be sure exploitation of NSA Away device (=key exfiltration) can not occur during the time the USB port is connected to the computer. As the requirement for bandwith is very low, consider adding "legacy support" for system with RS232 data diode between two 'RS-232 to USB' converters and maybe write a simple program for network connected computer that either simulates a keyboard, or prints the encrypted message, that can then be copied to email/IM application directly. Data diode is patented in US until 2017, but international users could have higher assurance.

Second issue is, how would the project with pre-built HWRNG mitigate the NSA's practice of shipping interdiction? How can customer trust the hardware isn't actually outputting PRNG stream with predetermined seed? This is why Tinfoil Chat was DIY.

You are right about not implementing QR-codes: it's more difficult to verify that no covert channels exist, than it is with OCR.

I'd also reccommend you over-write keys directly after they're used and disable logging by default: that way users have more assurance that already had conversations remain private in case the device is seized.

Message authentication was already discussed but remember also to add padding for messages.

Cheers,
Markus

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

Thanks for a bunch of great advice. Some thoughts:

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.

Thanks again!

Scott

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

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.

Scott

Are you sure? [yes] / [no]

Jon wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

jpixton wrote 2 months ago null point

One time pad is really not suitable for this.

* 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.

I like the overall arrangement of the system, though.

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

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.

Thanks for clarifying,

Scott

Are you sure? [yes] / [no]

Danny wrote 2 months ago null point

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

recipient: 1324534675689780
never received message.

sender: 534675689780
sends 4 letters again.

recipient: 1324534675689780
Can't decode.

Are you sure? [yes] / [no]

bob baddeley wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

Arcadia Labs wrote 2 months ago null point

Hey congratulations for accessing the semi finals ! I have a "similar" project that got to the semifinals also. I'm happy to see some strong interest in privacy, finally :)
Keep up the excellent work

Are you sure? [yes] / [no]

Big Dave wrote 2 months ago null point

Hey guys, nice project. Mine also uses a one time pad. Check it out here:

https://hackaday.io/project/2760-Pad-Thai-I---Easy-To-Use-One-Time-Pad-Router

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

Interesting project, thanks for sharing.

Are you sure? [yes] / [no]

Jon wrote 2 months ago null point

Check out tin foil chat which is very similar to this project: https://github.com/maqp/tfc/ and definitely read the paper lots of good info.

Are you sure? [yes] / [no]

bob baddeley wrote 2 months ago null point

Wow, you're right. Thanks for this. It has some great information.

Are you sure? [yes] / [no]

Jon wrote 2 months ago null point

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?

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

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?

Are you sure? [yes] / [no]

Liam Marshall wrote 2 months ago null point

How'd you get your RNG working? I'd love to know what was wrong with it :) Last I heard (http://hackaday.io/project/1569/log/6084-hardware-working-day-2) it was broken ;(

Are you sure? [yes] / [no]

Liam Marshall wrote 2 months ago null point

Oops, didn't see that you're (currently) using the pseudorandom generator ;)

Are you sure? [yes] / [no]

Jasmine wrote 3 months ago null point

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.

There are a couple of tutorial video's with more info here: http://hackaday.com/2014/07/26/4-minutes-to-entry/

Good luck!

Are you sure? [yes] / [no]

surubarescu wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

Scott Hasse wrote 3 months ago null point

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.

The mouse sensor is definitely an interesting idea.

Are you sure? [yes] / [no]

surubarescu wrote 3 months ago null point

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".

Are you sure? [yes] / [no]

Scott Hasse wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

Boz wrote 4 months ago null point

Nice,

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.

Still thumbs up.

Are you sure? [yes] / [no]

Scott Hasse wrote 4 months ago null point

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.

Thanks for the good question and thumbs up!

Are you sure? [yes] / [no]

ipaq3115 wrote 4 months ago null point

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.

Maybe an idea for version #2?

Are you sure? [yes] / [no]

Scott Hasse wrote 4 months ago null point

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.

Thanks for the feedback.

Are you sure? [yes] / [no]

Liam Marshall wrote 3 months ago null point

An OpenMV is powerful enough to do both encryption/decryption and recognition, as well as providing a UI. I definitely believe that the OpenMV design would be good to consider for v2.

Are you sure? [yes] / [no]

bob baddeley wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

Liam Marshall wrote 4 months ago null point

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?

Liam

Are you sure? [yes] / [no]

Scott Hasse wrote 4 months ago null point

@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.

Very insightful comment, thanks. I hope I've captured your concern appropriately, please let me know if not.

Scott

Are you sure? [yes] / [no]

[deleted]

[this comment has been deleted]

Scott Hasse wrote 4 months ago null point

Done, thanks!

Are you sure? [yes] / [no]

Adam Fabio wrote 4 months ago null point

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?

Are you sure? [yes] / [no]

Scott Hasse wrote 4 months ago null point

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:

https://github.com/Sector67/ocr-test-app/blob/master/README.md

Scott

Are you sure? [yes] / [no]

daytonpid wrote 4 months ago null point

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!

Are you sure? [yes] / [no]

pnovotnak wrote 4 months ago null point

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.

Are you sure? [yes] / [no]

Scott Hasse wrote 4 months ago null point

Great question, I've updated the Frequently Asked Questions above to include some clarification.

Are you sure? [yes] / [no]

visualkev wrote 4 months ago null point

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.

Are you sure? [yes] / [no]

Liam Marshall wrote 4 months ago null point

@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*.

The description doesn't make this clear.

Are you sure? [yes] / [no]

Scott Hasse wrote 4 months ago null point

@ArchimedesPi: Thanks for the clarification. I've updated the description to make this more clear.

Are you sure? [yes] / [no]

bob baddeley wrote 4 months ago null point

@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.

Are you sure? [yes] / [no]

Similar projects