Java Cryptography

Secure Systems

Computer applications enable people to do work. Applications are parts of a larger system (a business, usually) that also involves people, fax machines, white boards, credit cards, paper forms, and anything else that makes the whole system run. Secure systems make it hard for people to do things they are not supposed to do. For example, a bank is designed as a secure system. You shouldn’t be able to withdraw money from someone else’s account, whether you try at the teller window, or by using the bank machine, or by telephone. Of course, you could bribe the teller or disassemble the bank machine, but these things are usually not worth the cost.

Secure systems are designed so that the cost of breaking any component of the system outweighs the rewards. Cost is usually measured in money, time, and risk, both legal and personal. The benefits of breaking systems are generally control, money, or information that can be sold for money. The security of the system should be proportional to the resources it protects; it should be a lot harder to break into a brokerage than a magazine subscription list, for example.

The term “secure systems” is a little misleading; it implies that systems are either secure or insecure. In truth, there is no absolute security. Every system can be broken, given enough time and money. Let me say that again, every system can be broken. There are more secure and less secure systems, but no totally secure systems. When people talk about secure systems, they mean systems where security is a concern or was considered as part of the design.

The job of the application programmer is to make an application that costs as much to break as any other component in the system. Building a secure application usually involves a three-way balancing act. The cost of having your application broken must be balanced against both the application’s cost and the application’s ease of use. You could spend a million dollars to build a very secure application, but it wouldn’t make sense if the cost of a break-in would be measured only in thousands. You might build a moderately secure application instead, but it won’t do you any good if it’s too hard to use.

The security of any application is determined by the security of the platform it runs on, as well as the security features designed into the application itself. I’ll talk about platform security later in this chapter. Chapter 2, explains the concepts of security that can be programmed into an application. The most important tool applications use for security is cryptography, a branch of mathematics that deals with secret writing.

This is serious stuff! Unfortunately, in application development, security is often relegated to the we’ll-add-that-later-if-we-have-time list.^[1] Security should be a part of your design from the beginning, not a neglected afterthought. The information that your application harbors is valuable. The application’s users value this information; this implies that the users’ competitors and any number of third parties might also find the information valuable. If the cost of stealing that information is small compared with its value, you are in trouble.

The meteoric growth of Internet applications is closely shadowed by the meteoric growth of computer crime opportunities. The Internet is not a safe place. Only applications that are strong and well guarded have a place there. Even on a closed company network, applications should be secure, to limit damage or loss from authorized users. Even on a single, nonnetworked computer, applications should be secure, to limit damage or loss from unauthorized users.

The field of computer security is fascinating and volatile. In it you can find fire-and-brimstone security professionals, preaching about the dangers of badly applied cryptography, paranoid propeller-heads who believe the government reads everybody’s email, and a healthy dose of wide-eyed programmers who can’t understand why Sun made their lives so difficult with that damned sandbox thing. Overshadowing the whole field is the National Security Agency (NSA), an intimidating behemoth of unimaginable and unfathomed cryptanalytic power. The U.S. government, furthermore, categorizes some cryptographic software as weaponry and limits its export. All in all, it’s a combination of a tent revival and Star Wars. The stories behind cryptographic algorithms are much more interesting than the math itself.

This book describes the cryptographic classes in the Java Security API. The Security API is fresh and exciting, but it will not make Java programs secure at the drop of a hat. Security is a tricky, evolving mind game. The purpose of this book is to describe how you can use cryptography to make your Java applications more secure.

---

^[1] For a sobering assessment of secure system design, see Bruce Schneier’s paper, “Why Cryptography Is Harder Than It Looks...” at http://www.counterpane.com/whycrypto.html. Mr. Schneier is the author of the legendary Applied Cryptography (Wiley), which is a must if you want to understand the mathematics behind cryptography.