Java security evolution and concepts, Part 1: Security nuts and bolts
Learn computer security concepts and terms in this introductory overview
Computing models have changed drastically in the last few decades, and with the changes has come a greater need for application security in large-scale ecommerce and ebusiness systems, as the recent spate of denial of service (DoS) attacks on several popular sites demonstrates. More specific to the Java community, with Java emerging as the de facto standard platform for Internet programming, the ability to securely move Java code around is fundamental.
Java security evolution and concepts: Read the whole series!
- Part 1: Learn computer security concepts and terms in this introductory overview
- Part 2: Discover the ins and outs of Java security
- Part 3: Tackle Java applet security with confidence
- Part 4: Learn how optional packages extend and enhance Java security
- Part 5: J2SE 1.4 offers numerous improvements to Java security
This article, the first in a series, will cover the general concepts of computer security and cryptography. Although mobile code is not a revolutionary concept, Java and the Internet present some unique challenges to computer security. The evolution of Java architecture and its impact on security, the different security APIs and tools, and applet security will be covered in the subsequent articles.
This security series does not intend to provide a comprehensive guide to computer security. Computer security is a multifaceted issue touching several disciplines, departments, and cultures. Investments in technologies should be followed up with investments in personnel training, strict policy enforcement, and periodic review of the overall security policy.
Note: See the “Sidebar 1: Crypto Algorithm for the Twenty-first Century” for more on algorithm development and the “Sidebar 2: Does the Length of a Key Matter?” for a discussion on the importance of key length in security.
What is computer security?
To understand what computer security means in general, what security means in everyday life is worth considering. Some of the general rules for security in day-to-day life also apply to computer security, as we’ll see.
The limits of computer security
Is there such a thing as absolute computer security? In a word, no. The term secure systems is a misnomer since it implies that systems are either secure or not. Security, in truth, is a trade-off. Given unlimited resources, any form of security can be broken. While more and more resources are becoming available to the attacker, in the real world those resources remain finite. With that in mind, we should design systems in such a way that the cost of breaking them would far outweigh the rewards.
End-to-end security
What is end-to-end security? In a multitier system, each tier should have its own security and work in tandem with the other tiers. Designing security where different systems and middleware come together is quite a challenge. Simply put, system security is only as strong as the weakest link and, unless you consider security from an end-to-end viewpoint, it is subject to being broken.
Simplicity
Will a complex security design work? It might seem that the best way to stop an unauthorized user might be to design a very complex security scheme, but that’s not true. Not only will the cost of designing a complex security system be prohibitive, it might be so complex that legitimate users will try to find a way around it. Simple systems, on the other hand, are easier understood and better analyzed.
Good system design requires security
Is it possible to retrofit security? The answer is rarely. Quite often it may be impossible to retrofit security without having to redesign substantial parts of the system. In almost all cases, retrofitting will be very expensive. Therefore, security should never be an afterthought — it must be an integral part of the system design from the start.
Computer security basics
It’s useful to understand what computer security protects against, the respective defense mechanisms, and the different terminologies associated with it.
Threats
Threats — attacks against computer security — can be broadly categorized as:
- Secrecy attacks: Attempts to steal confidential information either by exploiting weaknesses in cryptographic algorithms or by other means.
- Integrity attacks: Attempts to alter information with some selfish or malicious intent. Integrity attacks, it should be noted, can also be accidental.
- Availability attacks: Attempts to disrupt a system’s normal operations. Availability attacks are also referred to by the recently popularized term, denial of service (DoS) attacks.
Several attacks fall into one or more of the categories mentioned above. Examples include:
- A brute force attack typically involves searching every key until the right one unlocks the door. While that may seem like an expensive operation, in reality it is possible to preen the search using specialized tools.
- A Trojan horse attack involves planting an enemy as an insider in such a way that it’s not apparently noticeable. A computer virus serves as a common Trojan horse example.
- A person-in-the-middle attack intercepts communication between two parties without their knowledge. They assume that they’re communicating normally.
Other attacks include: birthday attack, dictionary attack, meet-in-the-middle attack, and so on. (For a more comprehensive discussion, see Bruce Schneier’s Applied Cryptography in Resources.)
Protections
To shield against security threats, there are a variety of protection mechanisms. Historically, defense mechanisms have involved erecting some sort of a wall or boundary, commonly referred to as a perimeter defense.
Firewalls, a fairly successful example of perimeter defense, separate internal (private) and external (public) networks, and provide a central point of control for a corporate policy. However, firewalls increasingly allow select forms of traffic — HTTP for example — to cross over.
A virtual private network (VPN), which provides the same security level as a private network while still using a shared network, serves as another protection example.
Cryptography
Cryptography and cryptanalysis, its related field, concerns itself with the design and analysis of algorithms for encrypting and decrypting information. We’ll discuss cryptography’s vital relationship to security in the sections below.
Confidentiality
Confidentiality is the process of protecting data from unauthorized use or users. Simply put, it means that only the intended recipient of a message can make sense of it.
If you’re exchanging sensitive information with someone else, you want to be absolutely sure that only the intended recipient of the message can make sense of the message and, in the eventuality that it falls into wrong hands, the message becomes effectively useless. Confidentiality is accomplished by some form of cryptographic technique.
Authentication
The authentication process confirms the user’s identity. The user could be a software entity or a human. A principal is the party whose identity is verified. Associated with a principal is a set of credentials. Usually, authentication confirms identity by some secret information — a password, for example — known only to the user and the authenticator. Beyond passwords, more sophisticated security schemes employ advanced techniques such as smart cards or biometrics (finger printing, retinal scans, and so on) for authentication.
Once authentication is established, access to the user (or generally principal) is governed by the access control mechanisms in force.
Kerberos — based on keys and encryption — demonstrates an early authentication technology. It uses timestamps — sessions remain valid for a defined time period — to achieve that. To work properly, Kerberos fundamentally assumes that the clocks in a distributed system are synchronized.
Public key infrastructure (PKI), discussed in sections below, represents a more general authentication solution.
The Java Authentication and Authorization Service (JAAS) framework supplements the Java 2 platform with user-based authentication and access control capabilities. JAAS is a standard extension to the Java 2 Software Development Kit, v 1.3.
Integrity
Let’s say that you sent an electronic check. When the bank ultimately receives the check, it needs to be sure that the payment amount has not been tampered, a security concept known as integrity.
Nonrepudiation
In the electronic check scenario outlined above, if you indeed sent the check, there ought to be no way you can deny it. Nonrepudiation provides undeniable evidence of actions such as proof of origin of data to the recipient or receipt of data to the sender.
Auditing and logs
Keeping a record of resource access that was granted or denied might be useful for audit purposes later. To that end, auditing and logs serve the useful purposes of preventing a break-in or analyzing a break-in post mortem.
Policy and access control
A security policy focuses on controlling access to protected data. It’s important that the security enforcing mechanisms should be flexible enough to enforce the policy. That is referred to as keeping the policy separate from the mechanism. While that decision might be based on authorizing access to a resource based on the identity of principal, it is often easier to administer access control based on roles. Each principal is mapped to a unique role for the purposes of access control. It is often implemented as a list or matrix enumerating the access that different users/roles have to the different protected resources.
Java 2 Platform, Enterprise Edition (J2EE) uses role-based authentication for enforcement of its policies. With that in mind, in J2EE the developer of the business logic limits access to specific functions based on roles.
Cryptography: the science of secret writing
Although cryptography and computer security are two distinct subjects, computer security relies on cryptography in many ways.
Java.security, in conjunction with several core packages, provides some of Java’s cryptographic features. Javax.crypto is the primary package for some of the features that were governed by export control laws. Finally, the javax.net.ssl package can be used to create secure sockets when it’s necessary to transmit confidential information.
Next, let’s examine some of the concepts relevant to cryptography.
Cryptanalysis
Cryptanalysis, the reverse of cryptography, is the art of decoding or attacking secretly encoded information without access to the keys. Cryptanalysis has found security holes in algorithms using theoretical attacks that have either led to abandonment of the algorithm or a major refinement. It serves the critical purpose of analyzing and validating algorithms with the intent of making them more secure.
Cryptography algorithms
There are several algorithms to encrypt information. A simple algorithm might involve rotating a character of a message by 13 positions — referred to as rot13. Although not secure since the original message can be easily decrypted, rot13 still remains in vogue for insecure yet scrambled messaging.
Based on a nineteenth-century work by Kerckhoff, the security of a cryptosystem should rest entirely in the secrecy of the key and not in the secrecy of the algorithm. Secret keys with well tested and analyzed algorithms produce cryptographically secure systems. Correspondingly, many of the widely prevalent algorithms are available for public scrutiny. Cryptanalysis work on many of those algorithms have led to revisions that have made them stronger.
Note: See the first sidebar for a process to design the next generation of cryptographic standard.
One-way hash functions
A one-way hash function, H(M), operates on an arbitrary-length message and returns a hash value h of fixed length m.
h = H(M), where h has a length m.;
The security of the algorithm stems from its one-wayness, not the secrets of its inner workings. More formally, H(M) has the following properties:
- Given M, it is easy to compute h
- Given h, it is hard to compute M such that H(M) = h
- Given M, it is hard to find a message, M’, such that H(M) = H(M’)
Hashing is an essential part of digital signatures, discussed below. Ron Rivest of RSA designed MD4 (message digest) and MD5. (RSA is the name of a security company that stands for first letter in each of its inventors last names: Ron Rivest, Adi Shamir, and Leonard Adleman.) MD4 and MD5 produce a 128-bit hash. SHA (secure hashing algorithm), designed by the National Institute of Standards and Technology (NIST) in conjunction with the National Security Agency (NSA), produces a 160-bit hash used in the digital signature algorithm (DSA). SHA-1, simply referred to as SHA in some literature, is a revision to SHA published in 1994. SHA and SHA-1, part of the secure hash standard (SHS), share similarities with the MD4 function family. MD4, MD5, and SHA are some examples of one-way hash functions.
As an example, the following 128-bit hash was generated for similar looking messages based on the MD5 algorithm.
| Original Message | Hash value (in hexadecimal) |
| a quick brown fox jumped over a lazy dog | 13b5eeb338c2318b790f2ebccb91756f |
| a quick blue fox jumped over a lazy dog | 32c63351ac1c7070ab0f7d5e017dbcea |
| a quick brown dog jumped over a lazy fox | a4c3b4cd38ade6b5e2e101d879a966f5 |
For any arbitrarily sized message, the algorithm will generate a fixed size hash, which represents the message. It’s evident from Table 1 that altering a message even slightly will change its hash. It’ll be time consuming to find an alternate message that hashes to the same value.
So far we’ve discussed one-way functions that do not use a key. message authentication codes (MAC), on the other hand, are one-way functions that use a key. They can be used to authenticate files or messages between users, or on the system. HMAC (keyed hashing for message authentication) is an example in that category.
Symmetric ciphers
A symmetric cipher, when applied in conjunction with a secret key, translates plaintext to ciphertext. The cipher can also recover the plaintext from the ciphertext, using the same key. The symmetricity comes from using an identical key for both encryption and decryption. There are two related functions for encryption and decryption such that:
E<sub>k</sub>(M) = C, where M is the plaintext, C is the ciphertext and k is the key
D<sub>k</sub>(C) = M, where C,M and k have the same meaning
They have the essential property that D<sub>k</sub>(E<sub>k</sub>(M)) = M
Given a well designed algorithm, the security of the process lies in the secrecy of the keys. Consequently, the main challenge for symmetric ciphers rests in the distribution of keys — how do the communicating parties share the same secret key? In contrast, asymmetric ciphers do not have to use the same secret key. Instead, they rely on a widely available and freely distributed public key.
Encryption using private keys is usually faster than with public keys. In a hybrid cryptosystem, the private key for the session, referred to as a session key, is established using public keys. The communicating parties use the session key for the rest of the session. That is one form of key exchange. Other forms of key exchange use more secure channels to exchange the private key.
Symmetric ciphers are classified as stream ciphers or block ciphers. Stream ciphers operate on the stream of bits or bytes, whereas block ciphers operate on a group of bits. The essential difference in the ciphertext is that the same plaintext block will encrypt to the same ciphertext block, using the same key for block ciphers, whereas it will encrypt to a different block every time it is encrypted when using stream ciphers.
Most block algorithms obey the Feistel network property, which means that the algorithms for encryption and decryption are the same, with some difference in the application of keys.
There are several modes of operation. Modes enhance encryption and can also alter the characteristics of a symmetric cipher. As an example, a block cipher can be made to behave like a stream cipher by the use of the appropriate mode. Listed below are a few important modes:
- Electronic CookBook Mode (ECB)
- Cipher Block Chaining (CBC)
- Cipher Feedback Mode (CFB)
- Output Feedback Mode (OFB)
There are several block ciphers, including the data encryption standard (DES). DES will be replaced by advanced encryption standard (AES).(See the sidebar, “AES: Crypto Algorithm for the Twenty-first Century.”) Meanwhile, Triple DES (3DES or DESede), an improvement over DES, serves as a replacement until the AES is adopted. In DESede, the encryption procedure follows an encode, decode, and encode process using different keys in sequence, effectively increasing the key’s length.
Asymmetric ciphers
Unlike symmetric ciphers that involve the use of the same key for encryption and decryption, asymmetric ciphers involve the use of different keys in such a way that:
E<sub>k1</sub>(M) = C, where k1 is the encryption key
D<sub>k2</sub>(C) = M, where k2 is the decryption key
Asymmetric ciphers have the essential property such that:
D<sub>k1</sub>(E<sub>k2</sub>(M)) = M
In asymmetric ciphers, the communicating parties do not have to share the same key. However, the keys k1 and k2 are mathematically related for the encryption and decryption processes to work in conjunction.
Public and private keys
Asymmetric key ciphers are also referred to as public key cryptography since they involve the notion of a public key. A public key is freely available, whereas a private key is a secret. In a network of users, each user has his or her own public key published in a commonly accessible directory.
Whitfield Diffie and Martin Hellman and independently Ralph Merkle introduced public key cryptography in the mid-1970s. The security of public key algorithms is based on the difficulty of deducing plaintext from the ciphertext without knowledge of the key and the difficulty of deducing the private key from the public key.
It’s important to understand that discussion of public and private keys in most literature can get confusing since many articles appear to use the same keys for encryption and decryption, but it’s implicit in the discussion that one of them is the private key and the other the public key.
Another point to note is that when using multiple algorithms, multiple keys are required since the keys are unique to the algorithm.
Both digital signatures and certificates, discussed below, rely on public key cryptography.
Digital signatures
Digital signatures, much like real-life signatures, provide proof of authenticity of the sender and the integrity of the message. Digital signatures can be used for nonrepudiation — the sender cannot deny that he or she signed it. Digital signatures need to be unforgeable and not reusable to be successful, and the signed document must be unalterable.
The basic digital signature protocol is:
- The sender encrypts the document with his/her private key, implicitly signing the document
- The message is sent
- The receiver decrypts the document with the sender’s public key, thereby verifying the signature
Since signing large documents is time consuming, quite often only a hash of the message is signed. The one-way hash and the digital signature algorithm is agreed a priori. The original message is sent with the signature. The receiver verifies the signature by decrypting the hash with the sender’s public key and matching it with the hash generated against the received message. Figure 1 below illustrates the signature generation and verification process. That scheme also has a nice effect of keeping the document and the signature separate.
Notice that the message uses a hashing algorithm to generate a fixed size hash, which is then encrypted to generate a signature. Those signatures are sometimes referred to as digital fingerprints since they represent the original message in a unique manner.
Using digital signatures does not guarantee confidentiality since the message is sent as plaintext. To further guarantee confidentiality, instead of sending the plaintext message, it could be encrypted with the receiver’s public key, a process illustrated in Figure 2.
Digital signatures come in several algorithms, such as ElGamal signatures, RSA, or digital signature algorithm (DSA). Both ElGamal and RSA algorithms can be used for encryption and digital signatures. In contrast, DSA, part of the digital signature standard (DSS), can be used only for digital signatures and not for encryption. A separate algorithm for encryption has to be used in conjunction with DSA if encryption is desired.
Table 2 below concisely summarizes the characteristics of all the different cryptographic algorithms we have discussed so far and provides some examples in each category.
| Cryptographic Algorithm | Brief description | Security Property | Issues | Examples | Security Property |
| One-way hash functions | Produces a fixed-length unique signature | One-wayness of algorithm | Signature collisions | SHA, MD4, MD5 |
| Message authentication codes (MAC) | One-way function, using a key | One-wayness of algorithm | Signature collisions | HMAC | Authentication |
| Symmetric Ciphers | Encryption and decryption based on same key | Key length and algorithm | Key distribution | DES | Authentication, integrity, confidentiality |
| Asymmetric ciphers(public key cryptography) |
Different keys (public and private) for encryption and decryption. Public key easily available. |
Key length, algorithm and difficulty of deducing private key from public key. | Trust issue | RSA, ElGamal | Authentication, integrity |
| Digital signatures | Message hashed and encrypted with sender’s private key for authentication | One-wayness and key length | No confidentiality | DSA, RSA | Authentication, integrity |
| Digital signatures with encryption | Message signed and encrypted with receiver’s public key | Signature, encryption algorithms, and key length | Trust issue | Combinations of digital signatures and ciphers | Authentication, integrity, and confidentiality |
Certificates
Since digital signatures depend on the integrity of the public keys, how can verifiers be sure that the public key they’ve obtained did not come from an imposter? Also, while digital signatures authenticate the sender, how can the receiver be sure of the sender’s trustworthiness?
The answer to those questions lies in certificates. A mutually trusted third party or a certificate authority (CA) issues a certificate. The CA has more information about the user than merely the public key. Certificates contain, and an expiry date. The issuer signs the certificate with its private key. The implicit assumption in the process is that the CA’s public key is widely available and genuine.
Public key certificates are based on the X.509 standard. Some examples of CAs include Verisign, Thawte (now owned by VeriSign), and Entrust. In Java, the javax.security.cert package provides certificate support.
Public key infrastructure
The relatively new public key infrastructure (PKI) has several meanings in different sources. One view states that PKI refers to trust hierarchy and public key certificates, while another view holds that it also encompasses encryption and digital signature services. PKI also addresses several key-related issues, including key registration, revocation, selection, recovery, and so on.
Security standards
Table 3 lists a number of standards, some of which are complementary, and some are orthogonal to the algorithms and standards mentioned earlier. Those standards serve the useful purpose of being able to provide security, using commercially available products.
| Protocol/Standard | Brief description | Relevant Algorithms |
| IPSec (IP Security) | Cryptography-based security at the IP datagram layer | DES, 3DES, DH, MD5, RSA, SHA-1 |
| OpenPGP (Open Pretty Good Privacy) | Security services for email and data files | DES, 3DES, DH, MD5, RSA, SHA-1 |
| PPTP (Point-to-Point Tunneling Protocol | Used to create Virtual Private Networks | DES, RSA |
| SET (Secure Electronic Transaction) | Secure credit card transactions | DES, HMAC-SHA1, RSA, SHA1 |
| S/MIME | Security at application level | DES, 3DES, MD5, RSA, SHA1 |
| Secsh (Secure Shell) | Secure remote access | DES, 3DES, RSA |
| SSL (secure dockets layer) and TLS (transport layer security) | Secure pipe at the application layer | DES, DH, RSA, SHA1 |
Other security considerations
Besides the concepts needed to understand the technologies behind security, good computer security requires that systems administrators:
- Know thy enemy
- Identify assumptions and weaknesses
- Control secrets
- Remember human factors
- Limit the scope of access
- Understand your environment
- Remember physical security
- Make security pervasive
Those factors are equally as important, if not more, as the technologies forming the foundation of security.
A closely related issue to security and cryptography is privacy, which deals with the rights and responsibilities that govern the acquisition, disclosure, and use of personal information. Privacy needs to be considered in the design of a software system in general and the security features in particular.
Conclusion
In this article I have attempted to demystify the terminology behind computer security in general. Admittedly, there is a lot of terminology to deal with, but the fundamental concepts are simple. Beyond computer security, we’ve looked at cryptography’s importance to security and examined its main features.
In the next article in this series, we’ll relate those concepts to Java and its role as a programming language for the Internet. We’ll discuss the aspects of Java security, its evolution, and its unique challenges to computer security. Finally, we’ll touch upon issues that affect applet security; that is, the relationship of browser security to Java applets.
