INTEGRATING NETWORK CRYPTOGRAPHY INTO THE OPERATING SYSTEM BY ANTHONY GABRIELSON HAIM LEVKOWITZ Mohammed Alali | CS – Dr. RothsteinSummer 2013

Content  Introduction  Problems with the current implementation  Third part libraries  Proposed solution  Operating system integration  Network layer exploitation  TCP/UDP enhancement  More details.  Advantages  Disadvantages  Conclusion

Introduction  Cryptography is essential in today’s network communications.  Most of OS’s today are “natively” lacking (development wise).  Currently deployed cryptography implementations are often not secure.  General-purpose network cryptography library is needed.

The current approach  Third-party libraries:  SSL  Kerberos  PGP  Many others.

The current approach: problems  Inflexibility:  Non-intuitive.  Difficult to use (Steep learning curve.)  Diverse implementation  Compatibility:  Servers and clients have to match  Security:  Many security flaws  Design flaws: “4 a.m. design decisions.”

The current approach: problems  As a result, developers tend to  Incorrectly implement them, or  Avoid them. “In either case, security is compromised.”

Proposed solution  The authors introduce and define: A new general-purpose network cryptography library that integrates directly with the Operating System.  They argue that the best place for cryptography to be implemented is at the Operating System level rather than the current application-layer approach.

Proposed solution: OS Integration I  Currently developers must directly link their application to a cryptography library to enable secure communication.

Proposed solution: OS Integration II  The proposed solution is the general-purpose network cryptography that integrates with the OS’s kernel.

Proposed solution: Network stack exploitation I  Both transport and internet layers are utilized.  From the Internet Layer: Host info found in IP header is utilized to lookup cryptography keys. From host info, only “Destination Address” is need. No changes needed to Internet Layer. IP Host Info TCP/UDP Port Info

Proposed solution: Network stack exploitation II  From the Transport Layer: Port info found in TCP header is utilized to lookup cryptography keys. From Port info, only “Destination Port” is need. So both “Destination Address + Destination Port” are needed for cryptography keys lookup. Transport layer needs to be changed to natively support cryptography.

Proposed solution: TCP/UDP Enhancements I  Transport Layer (TCP/UDP) needs to be evolved:  Appending cryptography in the TCP header. The new fields to be added (Taken from PGP header) :

Proposed solution: TCP/UDP Enhancements II  TCP will also require an additional modification to streamline the key transfer process. The three-way handshake TCP uses can be enhanced to also transmit cryptography primitives. OriginatorDestination

Proposed solution: More details  The system described in this paper works with the Encryption Key System (EKS).  This system creates a chain of trust with a priori knowledge that is used to securely lookup keys.  The system leverages two distinct IDs to enable more security (DNS and EKS lookup).  This system also leverages a novel technique they called: “port-based sandboxing.”  enables the use of separate key pairs for individual services and users.

Advantages 1. Shifts community focus.  More security  More flexibility. 2. Offers smaller number of implementations which means fewer potential issues. 3. Easier for developers to use w/ existing socket API 4. Port-aware library supporting existing protocols. 5. Always up-to-date – same way w/ network sockets. 6. Available out of the box.

Disadvantages 1. Each host on the network requires a priori information, i.e., the EKS servers IP address and public key. How to securely transfer the server’s public key? 2. Certain types of protocols, like components of , will need to be updated. 3. Some applications would require small changes while other would require larger changes.

Conclusion  A general-purpose cryptography library has been proposed.  It is the only way to resolve the security and flexibility problems currently being experienced on the Internet.  It provides a unified library that is easier to adopt by developers.  It complements the existing transmission protocols; it does not replace them.

Thank you