Endpoint Security

Most of cryptography is concerned with securing communications between two parties. This requires two elements: cryptography for authentication and session encryption, and trusted executable code at each endpoint. It’s the “trusted executable code” that concerns us here.

Think back to the SafeTalk application in Chapter 10. How could it be compromised by messing around with class files?

  • You could modify the javax.crypto.CipherOutputStream class to send plaintext to another IP address, unbeknownst to the user.

  • You could modify the Session class to always choose the same key for encryption. Intercepted communications could then be easily decrypted.

And how would these class files be modified? A virus could do the work, or a rogue ActiveX control. If the class files come from a file server, they might be modified in transit from the server to your computer.

An interesting paper describes how a Netscape exectuable was modified in transit from server to client, available at http://http.cs.berkeley.edu/~gauthier/endpoint-security.html. The technique of NFS spoofing described in the paper could easily be used to modify class files instead of binary executables.

How can you prevent this kind of attack? Inside your application, there’s nothing you can do because it’s the class files of your application that get modified in this attack. Outside your application, you can take the following measures:

  • Don’t use an insecure file transfer protocol to obtain executables. In the paper ...

Get Java Cryptography now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.