ISO 7498-2: A Framework for Application Security (Part II)

Security continues to be a top concern for all businesses, regardless of size. Mistakes can be costly, embarrassing, and often highly-publicised — all of which can result in an adverse impact on your brand and your reputation amongst partners, suppliers and customers.
In Part II of this three-part series, we will look at confidentiality, integrity, and non-repudiation — the fundamental security services that make secure online transactions possible!
A Quick Recap on ISO 7498-2
The ISO 7498-2 standard provides a reference model for communicating between open systems. It also specifies a set of security services, which provides a useful framework when thinking about application security:
- Identification: Who are you?
- Authentication: How do I know you are who you claim to be?
- Authorisation: What operations and resources are you allowed to access?
- Confidentiality: How do we prevent others from seeing what you send me?
- Integrity: How do I know that what you send me hasn’t been tampered with?
- Non-repudiation: How can we ensure that the sender cannot refute the validity of a message?
- Auditing: Are we keeping accurate records of all activities and transactions?
Confidentiality: How do we prevent others from seeing what you send me?
Cryptography is used to ensure confidentiality. This involves the use of encryption algorithms to transform plain-text data into an encrypted format; once encrypted, only those who possess the correct decryption key will able to recovery the plain-text data.
There are two major types of cryptography:
- Symmetric-key cryptography (shared key) — in this type of cryptography, both the sender and receiver must share the same key. Symmetric-key cryptography tend to be much faster, but distributing the shared secret key in a secure and scalable fashion can be a real challenge.
- Asymmetric-key cryptography (public key) — in this type of cryptography, each party generates a pair of keys — a private key (which is kept secret) and a public key (which can be widely distributed). Since the private key cannot be practically derived from the public key, this solves the key distribution problem inherent with symmetric-key cryptography.
One important property of asymmetric-key cryptography is that a message encrypted with the public key can be decrypted only with the corresponding private key, while a message signed with a sender’s private key can be verified by anyone who has access to the sender’s public key. This property allows the same private/public key-pair to be used for both encryption and digital signatures.
In most modern cryptosystem designs, both asymmetric and symmetric algorithms are used to take advantage of the virtues of both. Asymmetric algorithms are used to distribute symmetric keys at the start of a session. Once a symmetric key is known to all parties of the session, faster symmetric-key algorithms using that key can be used to encrypt the remainder of the session.
Integrity: How do I know that what you send me hasn’t been tampered with?
A man-in-the-middle attack (MITM) is an attack in which an attacker is able to read and modify messages between two parties, without either party knowing that the link between them has been compromised.
Hashing and digital signatures are two of the most common approaches that can be used to ensure that message is not tampered with while it is in transit. Hashing and digital signatures work with plain-text messages as well as encrypted messages.
Hashing relies on a type of mathematical algorithm known as a hash function. A hash function takes a message of any length and computes a fixed-length hash value for that message. The hash value is typically much shorter than the original message, and is also known as a “message digest” or a “digital fingerprint”. Importantly, a small change in the input message produces large changes in the hash value — making it computationally infeasible to generate two different messages with the same hash value.
Hashing is used to verify that the message has not be tampered with while it is in transit:
- The sender applies the hash function to determine the hash value of the message sent.
- The receiver applies the hash function to determine the hash value of the message received.
- The sender and receiver compare the two hash values over an independent channel (e.g., over the phone). If the two hash values are identical, they can be certain that the message has not been tampered with while it is in transit.
Digital signatures go one step further by using public-key cryptography to encrypt the hash value:
- The sender applies the hash function to determine the hash value of the message sent.
- The sender encrypts the hash value with his/her own private key, and send the encrypted hash value (a digital signature) attached to the message.
- The receiver applies the hash function to determine the hash value of the message received.
- The receiver decrypts the digital signature with the sender’s public key, and retrieves the hash value computed by the sender.
- The receiver compares the two hash values. If the two hash values are identical, he/she can be certain that the message has not been tampered with while it is in transit and that it originates from a party that possesses the sender’s private key.
Non-repudiation: How can we ensure that the sender cannot refute the validity of a message?
Non-repudiation is the concept of ensuring that a party in a dispute cannot repudiate, or refute the validity of a statement or contract.
The fundamental problem with digital signatures is that messages are tied to the sender’s private key, rather than to the sender. This is an important distinction — if another party manages to get hold of the sender’s private key, this party can create perfect digital signatures that purports to originate from the sender.
Worse still, there is no certainty about the date and time at which the message was signed — if another party manages to get hold of the sender’s private key, this party can digitally sign “backdated” messages to forge messages that purports to have been sent before the private key was compromised!
From a non-repudiation perspective, this means that:
- With digital signatures, a sender cannot repudiate a message without first repudiating his/her private key.
- However, once a sender repudiates a private key (e.g., by claiming that he/she lost control of the key, or that the system storing the key was compromised), all digital signatures ever created by that key becomes suspect…
To meet the non-repudiation requirement, we need to introduce a Trusted Third Party (TTP) acting in the role of a Certificate Authority (CA) and another acting in the role of a Timestamping Authority (TSA).
Certificate Authority (CA)
A CA issues digital certificates that contains (1) a public key and (2) the identity of the key owner. A CA is responsible for verifying the credentials of the applicant prior to issuing a digital certificate — in this way, users of a digital certificate can be assured that the public key indeed belongs to the entity claiming ownership.
VeriSign, for example, will verify the existence of your business, the ownership of your domain name, and your authority to apply for the certificate, prior to issuing you with a digital certificate.
When the sender loses control over his/her private key, the digital certificate can then be added to the CA’s Certificate Revocation List (CRL), which contains a list of certificates that are no longer valid, and should not be relied on by any system user. As long as the receiver is properly configured to query the CRL every time he/she wishes to rely on a public key, this ensures that repudiated keys cannot be used to send forged messages.
Time Stamp Authority (TSA)
Trusted timestamps is defined by the ANSI ASC X9.95 standard. In this scheme, when a requestor requires a timestamp for a message, it first creates a hash of the message, which is sent to the TSA. The TSA then cryptographically binds this hash value and a timestamp into a timestamp token, which is returned to the requestor for association with the message.
Trusted timestamps provide non-repudiable evidence of who signed the data (authentication), when it was signed (timeliness) and what data was signed (integrity).
Looking Forward…
In Part III of this three-part series, we will look at auditing and logging — which can be extremely useful for identifying and analysing security breaches “after-the-fact”.