"Enabling secure storage capabilities for sensitive data through standardized methods of encryption or multiple agent distribution."
Our group chose to implement a secure form of storage for sensitive information such as passwords or identification numbers. This is modeled after Shamir’s secret sharing algorithm. It allows us to distribute information regarding the secret key among several agents. In this way, you would need a certain minimum threshold number of agents to collaborate to generate the secret key. With this base concept down, we needed a way to physically store and distribute this information. We decided to use Near-field communication (NFC) as the medium through which to transfer information. NFC builds on top of RFID and was chosen for both its limited range and versatility. Our current implementation stores information on NFC cards, but future enhancements can allow communication with other devices such as NFC-enabled phones. For demonstration purposes, we combined both the encoder and decoder into one device. The user can specify the number of agents and the threshold number to encode a certain key. The other option is to use the Advanced Encryption Standard (AES) to encrypt the data and store it on a single card. The user is able to choose either option and interact with the device through a keypad and a television screen.
Figure 1: System Photograph (TV not shown)
High Level Design
Rational and Inspiration Sources
There are many situations in which security is of great concern. One such example is gaining access to a restricted area. If the key requires a certain number of people present to decode it then you guarantee that no one person is alone in the restricted area. Similarly, if one is trying to move account numbers, encryption keys or even nuclear launch codes, you do not need to place the full burden of one person carrying the key; but instead, it can be split with several people. In this way, if any individual pieces are intercepted, there is not enough information to regenerate the key. By using NFC, there is great versatility in how the information can be stored. There are NFC cards, tags, stickers and phones widely available in today’s market. Its low range protects data from being intercepted by a third party in the distance. Additionally, for different types of data that are typically written to and read from tags, the transfer speed gets it done very quickly.
Hardware & Software Tradeoffs
In an attempt to reduce the amount of inputs coming into the MCU at once, we moved a lot of the controls for switching states from hardware to software. Instead of using more pushbuttons, we made our user interface more content-aware to detect valid and invalid inputs in order to cycle through the various states of the menus. We minimized the inputs to keypad entry and NFC card scanning in order to accomplish this goal. However, this increased the amount of overhead written into the program to handle the decisions in software. It then became a goal to optimize the program in order to handle the speed and timing constraints that each component required.
Applicable Standards
Our design complies with the NFC standard ISO/IEC 14443 A, which is the standard for interacting with contactless cards. The MiFare card complies with the mutual three pass authentication method as defined by ISO/IEC 9798-2 and is implemented in our pn532_spi.c library. The PN532 NFC Shield itself complies with the air transmission standard ISO/IEC 18092.
Hardware and Software Design
Program Details
The main program consisted of a large state-machine whose states controlled the television display and controlled the user’s different actions, such as encoding and decoding information to/from the NFC cards. The main difficulties in our program involved both being able to interact with components through NFC as well as getting all of the timing down on one processor in order to scan the keypad, run the television display, and read/write to NFC cards through SPI. The first obstacle was writing the library for interacting with the PN532 chip on the NFC shield. This component was not only designed to run on Arduino with its Sketch language, but the library provided by Adafruit was also in C++. This meant we had to write our own library in C to interface with the ATmega1284. The C++ library served as a useful guide when doing so.
Figure 2: System state machine diagram
Structure of the PN532 SPI Library
At its lowest level, the library has the basic read/write SPI functions. This served as the foundation from which to build the rest. The mid-level SPI code contained functions to send the write command to the NFC shield, read raw data, and read the SPI status. The high-level SPI code contains a SPI read with acknowledgment function. We took these functions and used them as tools to build functions that operated on a higher level that fulfilled more common functions. The sendCommandCheckAck was used in several places in the library as it allowed us synchronize the card and the antenna to begin read/write operations. The readPassiveTargetId function reads the unique identification number of the card, written by the manufacturer. Each number is unique not only to the manufacturer but also to any other card. Next are the readMemoryBlock and writeMemoryBlock functions that write information to a given block in the card. However, writing to a card is not as simple as sending information. The ISO 14443 type-A standard has certain procedures to be followed in order to write to the card. Specifically, type-A requires that a block be authenticated before it is read or written, which is what the function authenticateBlock does. The authentication procedure is what provides so much security in these NFC communications.
Concurrency Issues
There are four main processes that are supposed to run concurrently. The NFC shield is running continually, waiting for a card to read/write and communicates through SPI. The television requires a constant rate of pixel blasting in order to maintain an image. The MCU is constantly scanning the keypad, awaiting user entry. Lastly, we have our main program that interprets and synthesizes all the inputs that it is receiving at once. We had to use many of the tricks we learned in the digital oscilloscope lab in order to get all of these to run without colliding. The television provided the largest overhead, followed by the NFC shield, the keypad, and the main program. They were thus prioritized in that order to work out the timing. In the end, our program proved to be too fast to the point where we had to introduce delays in order to maintain the correct timing among the state machine. This greatly exceeded our expectations and became advantageous when implementing the rest of the program.
Hardware Details
The MCU used was the ATmega1284. A 16-button keypad with pins 0-8 was connected to pins C0-C7, respectively with a 330ohm resistor at every pin. The NFC shield was the PN532 NFC Shield from Adafruit Industries. A solder bridge over SEL0 and SEL1 was used in order to set it to communicate through SPI. The clock, MISO, MOSI, and chip select pins were connected to pins B7, B6, B5, and B4, respectively. This particular shield can function at either 3.3V or 5V, so the VCC connection was connected to the +5V pin. Lastly, the television sync was connected to pin D0 and the video to pin D1. Refer to Figure 5 in Appendix B for a diagram of the connections. We were originally working with the ATmega644, but reverted back to the ATmega1284 for the USART functionality, which was crucial to both constructing and debugging the system. As for NFC, we also had a few Maxim cards which were of type-B, different from the MIFARE which is type-A. The difference between these two types completely changes the way we write to them. There are different security protocols and after reading through a few data sheets, we decided against it for the sake of time.
Figure 3: Final Hardware Components Used
Results of the Design
Speed of Execution and Accuracy
As previously mentioned, the biggest factor affecting the speed of the design was concurrency. We had to run the television, the NFC shield through SPI, the keypad, and the main program. After a lot of optimization, we managed to comfortably run all four with minimal hesitation and a fast response to user interaction. Even with all the overhead, the timing of the video signal was accurate enough to avoid seeing much, if any, flicker, random points, or screen jitter. Testing the encryption is very simple given out current implementation. The state machine prompts the user to choose to encrypt or decrypt. It then asks for AES or Shamir. In the case of AES, it asks for an encryption key to use. After a 16 character key is input, it automatically enters the next screen and asks the user to input the data. The user can input a 16 character long password or code that he wishes to encrypt. Once 16 characters are input, the program automatically moves to the next screen and prompts the user to swipe the card. Once the card is swiped, the user is taken to the next string, indicating whether encryption was successful as well as repeating the encryption key to remind the user. Any key press returns to the main menu. With Shamir, the user is asked for the data, the number of agents, and the minimum threshold to regenerate the key. One can test the encryption by choosing decrypt from the main menu. With AES, typing in the wrong encryption key produces erroneous results and just prints a bunch of garbage to the screen. However, entering the correct key correctly decrypts the cypher and displays the decoded message on the screen. The same procedure is used to test Shamir’s algorithm, which will not compute the correct value without the correct number of agents. We saw accurate decryption every time.
Design Safety Considerations
The design does not have any moving, stray live wires, or high current. The NFC shield itself is contactless and the user can simply bring the card a few centimeters away for it to begin reading or writing. The keypad used for direct interaction is also safe and in a clear location for interaction without touching any of the circuitry. The same is true of the television, which has its isolated cables and can maintain a safe distance from the circuitry.
Interference and Usability
One of the original reasons for using NFC was for its limited range. The antenna operates at a specific frequency of 13.56MHz and has an effective range of up to 5cm. This means that it will not interfere with cell phone signals or any other receivers, even if they are nearby. Furthermore, this antenna does not work like a typical antenna, but instead emits an RF field through which NFC cards interact with through magnetic coupling. In this way, the antenna is simply a coil and can fit almost anywhere, even on the back of phones. Because interaction through NFC is contactless, it means almost anyone can use it simply by placing the card in the vicinity of the NFC shield. However, with the size of the screen being only a few inches across, reading the screen may be a problem for those with very troubled eyesight.
Conclusion
Design Analysis
Overall, the design seemed to meet a lot of our expectations, but not all of them. We had an idea of the amount of work involved, but it was not until we began writing libraries and interacting with the components that we realized how many different protocols existed for a myriad of devices. We expected to be able to interact with NFC-enabled cell phones, and any type of contactless card, but after writing the authentication procedures and all of the other steps required for one type of card, the MIFARE Classic, it seemed like we should move on to the rest of the project before trying to implement communication with the others. Time constraints did not allow us to do this, however, which made moving on the right decision in the end. With all of the components that we intended on running concurrently, especially the television, we expected a fair amount of jitter, flicker, and hesitation in the system. However, we managed to exceed these expectations and wrap the code in such a way that the four systems ran seamlessly. If we had to do it differently, we would interface a small keyboard instead of a 16-button keypad in order to add more user functionality to the design. We would also refine our graphical interface to make it look better in general. Lastly, we would try to implement communication with NFC-enabled phones.
Figure 4: Full System Functioning Properly
Applicable Standards
Our design used the PN532 NFC Shield which by design already conformed to the across air transmission standards defined by ISO/IEC 18092, broadcasting at 13.56MHz, transmitting data. The standard for interacting with NFC cards is ISO/IEC 14443 A. This is one of three main standards, and is the most commonly used, especially by MiFare, a large distributor of NFC tags. We implemented this standard in pn532_spi.c, our NFC library, by implementing the necessary request codes and commands before reading and writing to the NFC card. The MiFare Classic employs a mutual three pass authentication sequence that is necessary before reading or writing to the card. This three pass method is compliant with ISO/IEC DIS 9798-2 and is also implemented in the authenticateBlock method of pn532_spi.c. The successful implementation of these standards allowed us to the reliably and accurately communicate with both the NFC shield and the NFC cards that were already produced in compliance with those standards.
Intellectual Property Considerations
Since we maintained the same group the whole year, we referred back to code we wrote for previous labs to help us re-implement certain areas of the design such as interfacing with the television and scanning the keypad. We did not directly use code from the public domain, but we did use it as a reference point. Adafruit provides a public C++ library online for interfacing with its PN532 through SPI. This library was written to work with Arduino’s Sketch Language. We thus had to write our own library in C for the ATmega1284. We used their library as a guide for the necessary functions and procedures that we needed for interactions and being in compliance with the standards.
Ethical Considerations
Our group took much care to abide by the IEEE Code of Ethics. We acknowledge that any of the sources we used for reference or guidance must be acknowledged and we have properly done so throughout this document. The producers of our PN532 NFC shield, Adafruit Industries provided us with the necessary data sheets, user manuals, and libraries for us to get a jumpstart and begin using their product in our design. Cornell professor Bruce Land provided a great amount of help in debugging, design and conceptualization not only throughout the 5 week span of the project but throughout the whole semester in the other labs. We added the knowledge and advice from him, the teacher assistants, Adafruit, and Atmel and combined it with our own research and knowledge to produce this project. Furthermore, this project was meant to expand on the uses for NFC in combination with secure information exchange. Its purpose is to innovate on current methods of security and possibly inspire new ways to keep data secure as well as transfer it securely. We abided by the appropriate safety regulations in order to ensure that the user can interact with the device without causing danger to him/herself or anyone else. This device cannot cause harmful interference to any surrounding devices and as such has no malicious intent.
Legal Considerations
The source of our legal considerations lies in our transmitter. Our project uses an RF transmitter for NFC. The NFC shield produced by Adafruit Industries is built to be compliant with FCC regulations and at 13.56MHz, allows us to transmit and receive data from a powered to unpowered device or powered to powered device. The range is on the order of centimeters and the power is below 15mW. This device is thus compliant with the necessary FCC regulations for RFID/NFC communications.
