Close
0%
0%

NSA Away

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

scott-hasseScott Hasse
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Similar projects worth following
30.4k views
43 comments
858 followers
View Gallery
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.

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

Read more »

View all details
  • 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

View all 13 components

  • Build testing link

    Scott Hasse • 10/10/2014 at 15:41 • 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!

    Scott Hasse • 10/03/2014 at 12:37 • 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

    Scott Hasse • 09/22/2014 at 17:28 • 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!

  • Hardware update - practically everything works!

    Bob Baddeley • 09/21/2014 at 23:59 • 0 comments

    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.

    To expand on that, you can now

    • Create duplicate files on two SD cards of user-set size containing random data.
    • Output a given section of a given file from the SD card to the keyboard.
    • Receive data from the USB OTG Android device and print it out to the keyboard.
    • Generate random data and print it to the keyboard.

    Fun things you can do with this device

    Besides its original intention, this hardware will allow you to do all kinds of things. You could write additional code to get it to have more fun features, but consider these options:

    • USB Random Number Generator. These exist already as dongles (https://www.tindie.com/products/ubldit/truerng-hardware-random-number-generator/), but they're at least $30 for the cheapest I found. NSA-Away can do that and more!
    • USB<->Serial. Essentially two USB->Serial ports on this one device. So many options!
    • SD Card Management. You could copy any file from one to the other, or delete files, or wipe them. Go nuts!
    • Generic Dev Board. It's got a battery, 16x2 LCD, 4 buttons,...
    Read more »

  • Code Jam #6

    Scott Hasse • 09/15/2014 at 22:12 • 0 comments

    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.  

    Kate also created a nice set of icons for the Android app. 

  • Code Jam #5

    Scott Hasse • 09/08/2014 at 03:07 • 0 comments

    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.

  • Android encryption/decryption app update

    Scott Hasse • 08/20/2014 at 01:43 • 0 comments

    We've made significant progress on the Android application and a video walk through is available at:

    http://youtu.be/htllTVJe-zM

    The video shows test key generation, message entry, encryption, decryption and message viewing.

  • Hardware update - case and code

    Bob Baddeley • 08/18/2014 at 02:10 • 0 comments

    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.

  • Code jam #3 and #4 progress

    Scott Hasse • 08/16/2014 at 12:51 • 0 comments

    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.

  • Hardware working - day 2

    Bob Baddeley • 08/02/2014 at 16:25 • 0 comments

    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.

View all 19 project logs

Enjoy this project?

Share

Discussions

Dylan Bleier wrote 04/15/2015 at 04:45 • point

this is a great idea but you need true random number generation.... digital circuits will always have some predictability!

  Are you sure? yes | no

PowerPress wrote 12/05/2014 at 23:38 • point
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.

  Are you sure? yes | no

gordon wrote 11/03/2014 at 22:10 • point
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.

I am very interested in your project. Keep it up! --Gordon

  Are you sure? yes | no

[deleted]

[this comment has been deleted]

Scott Hasse wrote 09/07/2014 at 17:32 • 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 09/07/2014 at 17:40 • 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 09/04/2014 at 16:27 • 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 08/30/2014 at 10:43 • 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 08/30/2014 at 16:13 • 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 08/26/2014 at 15:21 • 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 08/26/2014 at 16:48 • 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 08/27/2014 at 02:34 • 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 08/26/2014 at 01:22 • 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 08/23/2014 at 11:07 • 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 08/24/2014 at 14:28 • point
Interesting project, thanks for sharing.

  Are you sure? yes | no

Jon wrote 08/19/2014 at 18:24 • 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 08/27/2014 at 13:35 • point
Wow, you're right. Thanks for this. It has some great information.

  Are you sure? yes | no

Jon wrote 08/19/2014 at 18:06 • 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 08/20/2014 at 01:46 • 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 08/18/2014 at 21:02 • 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 08/19/2014 at 20:55 • point
Oops, didn't see that you're (currently) using the pseudorandom generator ;)

  Are you sure? yes | no

Jasmine Brackett wrote 08/15/2014 at 22:39 • 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 08/09/2014 at 16:04 • 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 08/11/2014 at 14:14 • 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 08/11/2014 at 15:12 • 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 08/12/2014 at 02:45 • 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 07/15/2014 at 07:34 • 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 07/16/2014 at 04:50 • 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 07/11/2014 at 13:37 • 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 07/16/2014 at 04:55 • 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 07/24/2014 at 16:22 • 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 08/01/2014 at 13:51 • 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 07/07/2014 at 03:36 • 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 07/08/2014 at 02:18 • 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 07/07/2014 at 02:06 • point
Done, thanks!

  Are you sure? yes | no

Adam Fabio wrote 07/01/2014 at 04:57 • 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 07/01/2014 at 12:42 • 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

Dayton Pidhirney wrote 06/23/2014 at 06:40 • 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 06/23/2014 at 08:45 • 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 06/23/2014 at 17:31 • point
Great question, I've updated the Frequently Asked Questions above to include some clarification.

  Are you sure? yes | no

visualkev wrote 06/29/2014 at 18:07 • 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 07/02/2014 at 23:41 • 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 07/03/2014 at 00:58 • point
@ArchimedesPi: Thanks for the clarification. I've updated the description to make this more clear.

  Are you sure? yes | no

Bob Baddeley wrote 07/06/2014 at 03:14 • 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

A portable, solar powered, handheld device that provides truly global messaging when you have no alternative.
Project Owner Contributor

MyComm

john-grantJohn Grant

FIDO2 Arduino Authenticator
Project Owner Contributor

URU Card

andrey-ovcharovAndrey Ovcharov

Tired of remembering passwords, and unable to install a traditional password manager? This may be the device for you.
Project Owner Contributor

Keychain USB password manager

sam-pSam P

An operating system for larger microcontrollers, like Teensy 4.0, ESP32, or Artemis
Project Owner Contributor

NTIOS (Arduino OS)

dylan-brophyDylan Brophy

Does this project spark your interest?

Become a member to follow this project and never miss any updates

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2024 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "NSA Away", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.