General Security and Privacy Mechanisms for Liberty Identity Web Services Framework

Security in the Liberty Framework is layered. Liberty protocols are constructed with extensive security mechanisms. Furthermore they build upon various Internet protocols that themselves have embedded security mechanisms.  Table 1 generally summarizes the security mechanisms incorporated in the Liberty specifications, and thus in Liberty enabled implementations, across two axis: channel security and message security. It also generally summarizes the security-oriented processing requirements placed on Liberty implementations.

Table 1. Liberty security mechanisms

Channel security addresses how communication between identity providers, service providers, and user agents is protected. Liberty implementations must use TLS1.0 or SSL3.0 for channel security, although other communication security protocols may also be employed (for example, IPSec) if their security characteristics are equivalent to TLS or SSL. Note: TLS, SSL, and equivalent protocols provide confidentiality and integrity protection to communications between parties as well as authentication.

Critical points of channel security include the following:

1. In terms of authentication, service providers are required to authenticate identity providers using identity provider server-side certificates. Identity providers have the option to require authentication of service providers using service provider client-side certificates.
2. The authenticated identity of an identity provider must be presented to a user before the user presents personal authentication data to that identity provider.

Message security addresses security mechanisms applied to the discrete Liberty protocol messages passed between identity providers, service providers, and user agents. These messages are exchanged across the communication channels whose security characteristics were just discussed.

Critical points of message security include the following:

1. Liberty protocol messages and some of their components are generally required to be digitally signed and verified. Signing and verifying messages provide data integrity, data origin authentication, and a basis for nonrepudiation. Therefore, identity providers and service providers are required to use key pairs that are distinct from the key pairs applied for TLS and SSL channel protection and that are suitable for long-term signatures.
2. In transactions between service providers and identity providers, requests are required to be protected against replay, and received responses are required to be checked for correct correspondence with issued requests. Time based assurance of freshness may be employed. These techniques provide transaction integrity.

To federate, providers are required to join communities of trust such as PKI or Kerberos frameworks, or to establish bilateral agreements. These should include obtaining X.509 credentials, establishing and managing trusted public keys, and managing life cycles of corresponding credentials.

Many of the security mechanisms mentioned above, for example, SSL and TLS, have dependencies upon, or interact with, other network services and/or facilities such as the DNS, time services, firewalls, etc. These latter services and/or facilities have their own security considerations upon which Liberty-enabled systems are thus dependent

Public Key Cryptography

The purpose of a digital signature is to provide a means for an entity to bind its identity
to a piece of information. Digital signatures use PKC (Public Key Cryptography), which
employs an algorithm using two different but mathematically related keys: one to create a
digital signature and another to verify a digital signature.

Unlike conventional symmetric-key cryptography, which uses the same secret key for encryption
and decryption, PKC uses a key pair, a private and a public key, for encryption and decryption
operations (see Figure 1). The public key is freely available to anyone, but the private key
is protected and never shared. Each key pair shares a mathematical relationship that ties the
two keys exclusively to one another, and they are related to no other keys.

A cryptographic transformation encoded with one key can be reversed only with the other key. It
is computationally not feasible to deduce the private key from the public key nor to deduce the
public key from the private key. This defining nature of PKC enables the following:

• Confidentiality. A message encrypted with a public key can only be decrypted with the corresponding private key.
• Endpoint authentication. The recipient can determine the sender’s identity.
• Nonrepudiation. The sender cannot deny sending the message or committed actions.
• Message integrity. The recipient can easily identify whether anything has tampered with the message content during
  transit.

Encryption and Digital Signature

Digital signature

The process of digitally signing starts by taking a mathematical summary (called
a hash code) of the message. This hash code is a uniquely identifying digital
fingerprint of the message. If even a single bit of the message changes, the hash
code will dramatically change. The next step in creating a digital signature is to
sign the hash code with your private key. This signed hash code is then
appended to the message.

How is this a signature? Well, the recipient of your message can verify the hash
code sent by you, using your public key. At the same time, a new hash code can
be created from the received message and compared with the original signed
hash code. If the hash codes match, then the recipient has verified that the
message has not been altered. The recipient also knows that only you could
have sent the message because only you have the private key that signed the original
hash code.

Confidentiality and encryption

Once the electronic message is digitally signed, it can be encrypted using a highspeed
mathematical transformation with a key that will be used later to decrypt
the document. This is often referred to as a symmetric key system because the
same key is used at both ends of the process. As the message is sent over the
network, it is unreadable without the key. The next challenge is to securely
deliver the symmetric key to the bank.

Public-key cryptography for delivering symmetric keys

Public-key encryption is used to solve the problem of delivering the symmetric
encryption key to the bank in a secure manner. To do so, you would encrypt
the symmetric key using the receiver’s (Here Bank) public key. Since only the
receiver (Bank) has the corresponding private key, only the receiver will be able
to recover the symmetric key and decrypt the message.

Why use this combination of public-key and symmetric cryptography?

The reason is simple. Public-key cryptography is relatively slow and is only
suitable for encrypting small amounts of information – such as symmetric keys.
Symmetric cryptography is much faster and is suitable for encrypting large
amounts of information.