Category Archives: week8

Mobility First Final Report

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>

css.php
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar