Damian Lajara

August 30, 2014

NDN SECURITY AND PRIVACY

Today’s network architecture, which revolves around IP’s, has been around for many years, thus making it highly susceptible to cyber attacks. Not only attacks, but it also faces the problem of providing enough IP’s for our ever-growing population. Currently, there are roughly over six billion mobile devices in use today. Without counting desktop computers and other non-mobile devices, this number clearly exceeds the worlds population as of 2014. The current internet architecture may be able to handle that work load and traffic  now, but what about in the future? As mobile and non-mobile users continue to increase and technology continues to expand, the IP based network model will eventually start becoming vulnerable in many aspects such as efficiency and security.

Instead of having to reinvent the wheel and build another internet framework from scratch, the concept of a named data network or NDN for short, arose with the ability to be placed over the current IP layer without having to alter the design and the “hourglass” model. NDN is actually an easier concept to understand and a more efficient means of retrieving data than the current IP model we use today. At the IP level, or base,  NDN packets can be categorized into two different types: interest, and data. They will both contain a name to identify what the user is searching for, but will not contain any sensitive information to promote security. Once the request has been made and a control packet is issued, it will go from one router to the next looking for the information which matches the name. Using names instead of IP’s can drastically improve efficiency since the single-path forwarding constraints imposed by the current IP routing can be avoided making data the top priority.

With the evolution of technology, and with expanding internet architectures such as NDN, security has to be implemented in a way which completely differs from today’s current network security. This is where the idea of using keys to secure data comes in. So the producer digitally signs and encrypts the data using a private key, which no one should have. Since that private key was used to encrypt the data, the consumer can trust any kind of data. Just as the private key is used to encrypt the data, the public key can be used to decrypt it. To check if someone stole your private key or the data is malicious, simply try to decrypt it using the public key. If it decrypts, then the data is real and if it doesn’t, then the data is malicious and the private key was stolen.

Since every NDN data packet is signed at the “thin waist” part of the hourglass figure, and the generated security signature is embedded into the packet itself, it provides more of an abstract security feeling as compared to that of the original IP model. The newly created signature is then sent along with the packet inside the signature field, where it also has important information regarding the signature verification. One of the key features of using names is the key locator field. This indicates the name of the key that was actually used to sign the packet, so the receiver can retrieve the key from here at any point to verify their signature; however, just as the receiver can retrieve the key, so can a malicious hacker. This is one of the security vulnerabilities imposed by using names that affect signature privacy.

In order to prevent hackers from injecting malicious threats and faking content, a network administrator will be constantly checking the data to see whether the keys are fake or not in the network. Since this administrator is checking the authenticity of keys, it will also be easier if it signs the public keys as well. This way there is only one administrator handling everything thus making network management that much easier. On a small scale, this may even seem perfect and highly efficient, but once it reaches the point where this specific administrator or trust anchor has to sign a large number of keys, it raises a red flag in the security field and tends to pose high risks. To counter this potential threat, the NDN would have to have a hierarchy, similar to the IP hierarchies we currently have, which will consists of five levels: the root, site, operator, router, and NSLR. This is basically the same idea as data encapsulation.

The idea of breaking everything into parts, and having each part focus on a specific task takes the load off of the root, or administrator, thus decreasing potential risks, and increasing security. Following this model, the root key will sign the site key, then the site key will sign the operator key, then the operator key will sign the router key, which will then sign the NLSR key. Finally, the NLSR key will then sign the original routing data. To order these keys there are prefixes and tags used to differentiate the type of key in the hierarchy such as: <network>, <site> and <router>. An example key name for data being signed by an operator may be: “/<network>/keys/<site>/%C1.O.N.Start/<operator>”. Doing this results in the limitation of the signing scope making verification that much easier as well. To verify the data packet will simply be checked against the NSLR key, which will then be verified by the router key, which will be verified by the operator key, which will be verified by the site key and finally be verified against the root key which is owned by a network administrator. The magic that makes all of this work is the hash of the key at the end of every key name which is what’s actually being compared and verified. Keys of course have to be transmitted along with the data packet just as the signature does. Once the packet is signed, the key is put inside the “SignedInfo/KeyLocator” field.

So far, with the ideas, plans and implementations of NDN into this new network architecture, I can see that the IP model will steadily become something of the past. What really separates NDN from the actual IP based model is that NDN packets actually address and prioritize content instead of end-points such as source and destination addresses like IP does. This makes it that much harder to target a specific host thus resulting in better security. Aside from the security, NDN even offers better privacy, since it only tracks what data is actually being requested, and not who is requesting it, which keeps the users identity unknown. Since the concept of NDN is not finalized yet, and there is still extensive research being conducted, it’s fairly reasonable that not every possible security flaw has been targeted. Some key factors which will help in further improving security are: a way to figure out how to make the signing, transmission and verification of signatures more efficient, a better trust system that will efficiently, securely and precisely distribute routers’ cryptographic keys as well as a way to derive trust in the encrypted keys, a way to counter Interest flooding attacks and content pollution attacks and finally a way to secure better name and cache privacy. Once all of these aspects get implemented into NDN, IP will surely become extinct. The future internet is about to become that much more interesting!

Works Cited

Zhang, Lixia, Alexander Afanasyev, Jeffrey Burke, Van Jacobson, Kc Claffy, Patrick Crowley, Christos Papadopoulos, Lan Wang, and Beichuan Zhang. Named Data Networking. Tech. no. NDN-0019. N.p., 10 Apr. 2014. Web. 30 Aug. 2014. <http://named-data.net/publications/techreports/tr-ndn-0019-ndn/>

Zhang, Lixia, Deborah Estrin, Alexander Afanasyev, Jeffrey Burke, Van Jacobson, James D. Thornton, Diana K. Smetters, Dmitri Krioukov, Gene Tsudik, Kc Claffy, Patrick Crowley, Christos Papadopoulos, Tarek Abdelzaher, Dan Massey, Lan Wang, Beichuan Zhang, and Edmund Yeh. Named Data Networking (NDN) Project. Tech. no. NDN-0001. N.p., 31 Oct. 2010. Web. 30 Aug. 2014. <http://named-data.net/wp-content/uploads/TR001ndn-proj.pdf>

“2010 – 2011 Progress Summary – Named Data Networking.” Named Data Networking. N.p., n.d. Web. 01 Sept. 2014. <http://named-data.net/project/ndn-ar2011-html/#25Security_and_Privacy>

Okay, so for week six, I learned all about a click modular router, but before I talk about this software router, let me just say that technology is scary! Technology is advancing every single day, and with every day there are improvements to daily things that leave you speechless! You end up with thoughts like: “how did they do that? and “how is that even possible?”. This is exactly what happened to me during the presentation. I had no idea that a click modular router was even possible. I grew up watching the cable company come into houses installing their routers to connect to the internet, but now it’s finally time to let that go. Out with the old and in with the new! With these new software routers, you can easily customize and modify them to fit your likes, since it’s not being controlled by companies. The purpose of the click modular router is to be able to make any linux computer a router! How amazing is that? You don’t have to buy these expensive routers anymore and you definitely don’t have to be calling the company of the router to help you with troubleshooting problems. With the click modular router, you can easily implement it yourself, and tweak it to your needs unlike traditional routers who hide the low-level software from the user and limit the control you have over it’s configuration. I think I find this topic about software routers very interesting because it’s written in C++. Since, I already know C++, understanding the nature of these new routers, and how to install and implement them isn’t something out of this world. I truly believe that some day in the future, these click modular routers will replace the traditional routers to the point where everyone will start questioning why they haven’t switched to these new software routers earlier!

Week 5’s lecture on routing and transport was interesting but didn’t really leave a huge impact on me like the previous weeks. Probably because I still haven’t switched over from the current network model we use today to the mobility first one. For starters, the idea of being able to communicate with other devices without having an internet connection is incredibly absurd! I feel nothing but admiration towards the ones who developed and are still developing mobility first. They are trying to create a movement that will undoubtedly shake the whole world! During the presentation, however, there was one topic that actually got me a little bit interested.The whole idea of sensor networks and how they are used in real world scenarios. The example used in the presentation was volcanoes. As soon as a volcano is ready to erupt, the sensors, or nodes, detect the vibrations caused by the seismic event and send them to the main device, or base station, which is being monitored by scientists to record the data being received. The problem with these nodes is that they have to run on battery, since there are various factors that prohibit people from changing them such as the amount of danger, cost, time consumption and the distance, so the network may get partitioned when a lot of the sensors run out of battery. Using these sensor networks, scientists are able to figure out when a volcano may erupt before it actually does, which, to me, is just plain awesome!

Week’s 4 lecture was very shocking! I now view the world in a completely different way. I had no idea that there are over 6 billion mobile devices in use today. This clearly portrays how the number of mobile devices exceed the world’s population, but what I find really shocking is how it’s only 2014! What does the future have in store for us? If the mobile-connected devices exceed the world’s population as of now, and the world is just beginning—the population is increasing by every day and technology is expanding as every second passes—how will the world end up in, lets say, 4-8 years from now? According to Cisco’s VNI (Visual Networking Index), by 2018 the monthly global mobile data traffic will surpass 15 exabytes (15 billion gigabytes)! That is to say, the amount of storage 15 billion gigabytes would hold will be roughly 50 thousand years worth of high definition videos. That is an extremely large amount! Aside from the global mobile traffic, mobile network connection speeds will increase two-fold and the amount of traffic an average smartphone will generate will increase five-fold! This is exactly where mobility first has to take a stand. As mobile users continue to increase and technology continues to expand, the IP based network model will not be able to handle all of that traffic.  Mobility First plans to change the way the network works, and instead of using Ip’s it will use names (GUID’s). Aside from the GUID’s there will also be human readable names and network address locators. Even though this topic is still under research, the idea and concept is there, and if this takes over the network we currently have in today’s society sometime in the future, I believe that the internet will be a better, faster and more reliable network than ever before!

After all those weeks trying to understand the theory of mobility first, I was finally able to have a look at the mobility first API, but before I was able to look at the code, I had to understand how the code functions. The mobility first API is basically broken down into different network service abstractions such as: name-based services, direct addressability of all network principles, trust and privacy, point to multi-point communication, and in-network storage and computation. The name-based services basically treats everything as names instead of location like our current network architecture does. The direct addressability of all network principles is the namespace in which all the names will reside. The bit space is so large, in fact it is (2^256). That number is so large, it can basically be considered infinite. The trust and privacy part of the mobility first network architecure is what handles all of the security and signs every name with a public key, which can later be used in combination with a private key to decrypt and authenticate it. The point to multi-point communication is what handles the routing and forwarding of messages accords the network using protocols such as unicast, multi-cast and any-cast. The last network abstraction, in-network storage and computation, is basically the brain. This is where data is stored and cached. It can then use this data to improve the routing efficiency and even use it to send messages to devices (nodes) that have been disconnected or out of reach. It’s finally code time! After learning how mobility first functions, I learned the syntax and how to actually use the API code. I learned how to open and close a mobility first socket, how to send and receive name-based messages and even how to attach and detach additional GUID’s. It was an awesome week. It’s so sad that there is only one week left, but this is just step one. I can use the experience gained from this workshop to create my own apps and make them compatible with mobility first! Finally, onto the last week where I had to present my app and write a final report about my knowledge about NDN and security.

I can’t believe time flies so fast! It is already week 7, which means there is only one more week left of the android workshop! Time to get the gears moving and the app working! My first task was to figure out why the app on the receiver side was crashing. This is when logs come in handy. I put logs everywhere so I can understand how the code is functioning and I found out that it crashes right before the receiver tries to open it. This clearly means that the receiver is trying to open something that either doesn’t exist or is damaged somehow. After thoroughly debugging my app, I found out that the intent was setting two types of data in different places, so I was sending some weird unrecognizable file instead of a .txt file. This problem involved me changing a lot of code which would obviously be error prone, so I decided to drop the idea of sending a .txt file and simply create a new .txt file on the receiver side and populate it there. So the first thing I had to do was retrieve the contents of the sticky note and store it in an intent, which I then passed it to the other device. The other device then reads the intent and gets the contents and stores it in a variable. I then created a new .txt file on the other device, populated it using the content from the intent it received, and then opened it in full window mode with an option to edit the sticky, since by default it is opened in a non editable screen.

I was able to successfully get the contents but the title was messed up! Since the creation of the title was taking place in another thread, there was no way for me to send the title through an intent, so thats why the default title shows up. I tried everything I could possibly think of, but there is just no way for the two threads to meet exactly where I want it to. Now that I have the foundation laid down, I can work on the minor details such as adding a save function, adding a way to retain the color of the original sticky note, fixing the title, and of course a way to send it back, since so far the communication is unidirectional. So on to the week 8, where everything comes together!

After giving it some thought, and asking some friends, I figured out a way to fix the problem I was having during week 5, but before talking about that, I have to talk about an important step I was forgetting. Without this step, how can I even think of sending a sticky note. I was getting so ahead of myself, that I completely forgot about the most important part: the list of files the user can select from! Without showing the user a list of sticky notes he/she currently has on their phone, how can they possible even send it? This is when all the problems started occurring. For starters, the most puzzling decision I had to make was whether to create a new list view activity to show all the sticky notes saved to the phone, or to simply use the one I already had and make changes to it. Now, the hard part about making those decision was the nature of interactivity the user has with the list view. My application has the list view registered with onClickListeners that is fired when a sticky note is selected, so the sticky note is then opened in a new activity in a full screen mode. I also have a contexual menu, so when you long press a sticky note from the list, it will show a popup of different options; however, I don’t need any of that functionality for sending it to another device. If I reuse the list view I already have, I will have to de-register the listeners I have and create one that will implement the sending using Wifi_Direct instead of opening it in a full screen mode. This felt like over-kill for what I wanted to do, since I don’t have enough time to fret over simple details like that. Maybe in the future I can change it and work on reusing the list view I already have, but with the time constraints I have, I felt that the easiest way was the best, and the easiest way is of course just creating a new list view with its own properties.

After I finished the second list view, I was finally able to work on the Wifi-Direct aspect of my project. Now After both devices were paired and connected to one another, the second list view will appear allowing the user to select a sticky note to send. Now it’s time to go back to the hardships I was facing with the actual implementation of Wifi-Direct. The sad part was that I still didn’t know the best way to go about doing that. Considering the way I implemented the host side, the receiver (host) will have  to save the .txt file, and then search for the actual file that has been saved, and if it matches the title of the .txt file sent, then it will open it. That’s the way I tried doing it, but the problem with that is that all of this is happening in a different thread, so I can’t save the title or information inside a bundle or shared preference since it cannot be called within a static function. So for example, if I save the information in a shared preference or a bundle and I commit it, then when I go to retrieve the content, it still hasn’t been created since the other thread is running parallel to the current one. In order to save the information, I will have to come up with a way to either slow down the other thread (which is not efficient, and may cause future problems) , or try to save it after the code has ran in the other thread. However, Using this method raises another problem because the other thread is what handles the renaming and sending of the actual sticky note. If I try to save the information to access in the main UI thread, the parallel thread never sees it. After messing with the code I was able to send the file successfully but the sticky note would not have the appropriate title and application would crash on the receiver side. This, however, was a problem I had to face in the next week. Hopefully all goes well in week 7!

To be honest, even in week 5, I still didn’t have a concrete understanding of how to use Wifi-Direct. It’s been two weeks since I started messing around with the Wifi-Direct API’s and source code, but I still didn’t know how to use it to work with my app. I knew  how to create a simple chat application using wifi-direct but that’s about it. The problem was learning how to change the type of data being transferred. For my application, I had to find a way to send the sticky note across the another device, but there was nothing online to serve as a reference. So for about half the week I was focused on breaking down the sample source code that android provides. I added debugging logs everywhere in the code so I can understand what exactly is happening and when. With only two days left until week 6, I finally figured out how everything was tied together. It was finally time to start working on my application! The first thing I had to do was to try to connect to another device via Wifi-Direct. Even though I spent so much time reading through the documentation and everything, when it was time to actually implement my own code I was completely lost! So for the rest of that day, all I did was mess around with code to see how it fits and reacts with my application. Finally the last day of the week came and I still didn’t have any concrete work done! Finally, At the verge of despair, my cousin came up to me and said: “Why don’t you just use the sample code from the android website as a placeholder to build your app? After that you can stress on how you can change it to fit your needs”. As soon as my cousin said that, I felt so dumb! Why didn’t I think of that sooner? I wasted so much time on trying to build my own foundation, when in fact it was already built for me! Okay, so for the rest of the day I worked on making the android sample program work with mine, which was an obstacle in itself, but after countless hours of learning what goes where, I was finally able to piece them together! So, when a user clicks on “Share with friends!”, it will switch to the Wifi-Direct activity where it will connect to other peers. The first picture is what happens as soon as you select “Share with friends!”, and the second one is how it looks when another device becomes available to connect to.

After Selecting another device it will pull up a view with specific details about the connection as well as information about the device itself with two buttons allowing the user to either disconnect or select a sticky note.

After the user selects “Select Sticky”, the app crashes. It took me a while to figure out the problem. It just so happens that the program was trying to open any type of file, instead of the actual sticky note, so it didn’t know which file was trying to open, hence the crash. I had to deliberately change the mime type as well as make a few changes to the client code, to make it receive the sticky note. Just when I thought the code was perfect, it crashed yet again! After putting logs everywhere, I came to the conclusion that I could not send sticky notes, since the application did not know what a “sticky note” was. It took me so long to figure out the answer, even though it was so simple! The sticky note that I am sending is simply a .txt file, so instead of sending the “Sticky note”, I just have to send a .txt file to other device. Now this is where it starts to get complicated. In order to successfully send a .txt file is pretty easy, but I have to send a “sticky note” that is completely the same as how the user last had it. For example, if I create a new sticky note, and add a title and some content to it and I save it, I want the user to receive it the same exact way as I have it. Now my first thought was sending an empty .txt file, then populating it over at the client side, but thats repeating a lot of code and breaks the very first rule every programmer should follow: DRY (Don’t Repeat Yourself). Aside from breaking this rule, it wouldn’t every efficient. For the rest of the week, I focused on coming up with an idea of how to handle this problem. I even went out to staples and bought a white board so I can write pseudocode and draw diagrams to help organize my thoughts. Hopefully in week 6, I will have thought of a way to address this issue in a proper and efficient way.

I finally finished week 4! If there was one thing I really learned during week 4, it would have to be that I learned nothing! This is, by far, the hardest assignment I have ever done or even faced in my whole entire life. At first, I was fine with android. It was a little tough, but comprehendible, but as soon as I was forced to learn how to incorporate the Wifi-Direct API’s into my project, it became a nightmare! The documentation is very poor, the examples are way too basic and the concept is too vague. So much so, that after spending almost my whole week just reading and messing with the examples and tutorials provided by android, I felt like all hope was lost and I simply just  wanted to drop out. The only productive thing I got out of this week was that I had finally thought of an idea of how to use Wifi-Direct inside my sticky note Application. My idea was really simple, yet extremely fascinating…well at least for me. Once the user clicks on the share button, it would connect to nearby devices using Wifi-Direct and then it will show the user a list of all the sticky notes he/she has saved on the phone. After the user selects one of the sticky note files, it will send it to the other device that has opened a connection, and they will receive it in a full screen mode. Aside from viewing it in a full screen mode, the user should be able to edit it also, and even send it back to the original sender! I had everything set up and ready…well at least in theory anyways. The actual code was ridiculous. I was so lost, that I didn’t even know where to start. After hours of looking through online source code and examples of the Wifi-Direct API’s, I decided to forget about that for the moment and try to refresh my mind by working on something that seemed possible at the time. I then started looking through my code and realized that my photo button in the menu was  just taking up space that I can use to create my “share” button and the default logo for my app was too simple. So for a few hours I worked on deleting everything that had to do with taking a picture, and replaced it all with the code needed to switch to the Wifi-Direct activity, which I still didn’t have, but at least I was laying down the foundation for it. After completing that, I worked on the logo. I really didn’t have the time to spend making an official logo using Adobe photoshop or illustrator, so I just used the sample picture that I was using as a “splash screen” to create the logo using the Image Asset function in Android Studio. The screenshot showing the new menu and logo can be found below:

Finally everything was in place and it was time to actually implement the Wifi-Direct features into my application. So onto week 5 we go!

This week, things were a tad bit different from the previous days. The expressive internet architecture, or XIA, for short, is not trying to change the narrow based hourglass model, but instead is trying to make it evolvable. This is  a huge difference compared to other project funded by the Nation Science Fund. In today’s internet, everything revolves around IP. For example, if the client requests something online, the client has to retrieve the information from a server somewhere using packets that hold the client’s IP address as well as the servers IP address. On top of having all these IP’s, the client also receives specific information about the server from which it received its contents. XIA is basically trying to change this. XIA states that the client doesn’t need to know anything about the server. It just needs to know how to get the information in a timely and precise manner. In order to do this, they have to change how the client and server communicate. Instead of using IP’s to figure out the source and destinations, XIA wants to use ID’s. Instead of having to go directly to a server to retrieve content, they want to go directly to the source of the content and retrieve it using the client and content ID instead of using today’s model of client and server IP’s; however using this model raised serious security issues because there was no way to find out if the content was secure. To attack this problem, XIA decided to use hashes. By using content hashes,  the content can be easily checked to see if it’s malicious by comparing the hash to the ID. The hash can be a function which receives the content as a parameter and returns a unique string of numbers, which is then used to compare to the ID. If the string matches the id, then the content is secure. An example of a hash function can be MD5, which is the most popular hash function designed by Ron Rivest. After finding a solution to this issue, another problem arose: what if the router does’t know where the content is, or maybe what if it doesn’t know show to reach it? The solution to this problem is fallbacks. If your trying to reach a CID(content ID), SID(service ID), HID(Host ID), or even UID(User ID) and using the original primary path isn’t an option, then it will simply “fallback” and use different hosts to reach the original destination. The theory and concept behind this seemed so interesting that I had to check out the source code, but it was so complicated that it made me realize something: If the code is really that complicated and the project is still under research, then that means that the code is just going to get more complex, isn’t it? The fact that the internet is so large, and yet people are trying to change the way it works, to me, is just so amazing!