Message Security + and –

Secure the message – don’t need underlying protocol to be secure

Securing XML is complicated and an overhead -

Different parts of a message can be secured in different ways +

Asymmetric: different security mechanisms can be applied to request and response +

Self-protecting messages (Transport independent) +

Transport Security + and –

Rely on underlying protocol to secure the message for you

REST but may need more than this…

Widely available, mature technologies (SSL, TLS, HTTPS) +

Understood by most system administrators +

Point to point: The complete message is in clear after each hop -

Symmetric: Request and response messages must use same security properties -

Transport specific -

Transport and Message Security

We will discuss:-

enough background to be able to understand these topics

encryption, digital signatures, certification

TLS/SSL & HTTPS

transport security

How RESTful web services can be made secure in a modern environment using OAuth and OpenID

transport security

how SOAP-based communication can be made secure

message and maybe transport security

WS-Security and its associated standard

Securing REST

TLS/SSL

requires both public key and symmetric key encryption

requires digital signatures

requires certificates

ultimately it provides a secure connection-oriented “data-pipe” guaranteeing the identity of the server to the client i.e. confidentiality, integrity and part-authentication

HTTPS

standard HTTP request-types and responses over TLS/SSL

extensible authentication of user to the server

OAuth

optional on HTTPS but increasingly everywhere esp. in the cloud

authorisation i.e. what you are allowed to do to what resources

OpenID

optional on OAuth and provides distributed, federated third-party identity guarantee service

authentication of user to the server

2 families:-

Symmetric keys (sometimes called secret or shared keys): shared secret session key (which must be transmitted securely). The function and its inverse to decode it (which are usually the same i.e. a symmetric algorithm) are publicly known. Breaking usually involves comparing plain and cipher text and attempting to deduce the key; cryptographers relying on their choice of encryption function to make this type of attack very difficult e.g. AES

Public keys (sometimes called asymmetric keys): the recipient principal generates a two part key (using an algorithm based on very large primes, the two parts are mathematically related). One part is the public key which is used by the sender; the other is the private key which is retained. The sender can encrypt the message but only the recipient can decrypt it e.g. RSA. It is important that public keys are authenticated (certification) and can thus be proven not to have come from an impostor either by: using a key distribution service as above or by distributing it with a digital signature.

Encryption

Apply a rule to translate plain (or clear) text to cipher text, and back again.

Need encryption algorithm and a (typically infinite) set of keys.

no point in trying to keep encryption algorithms secret

should be computationally efficient

keep the key secret

secure key transmission

authentication required

Compress before encryption.

encryption algorithms should produce output which is statistically indistinguishable from random numbers

no compression algorithm will considerably compress random numbers

so encryption before compression does not make sense

Encryption Algorithms

Symmetric algorithms are faster than public key algorithms; using public keys is more convenient.

Common symmetric algorithms in use:-

AES (Rijndael) – 256 bit keys; RC4 (now to be avoided)

Common public key algorithms in use:-

RSA, DH, DSA (at least 2048 bit keys recommended)

Encrypted data is binary and may need to be sent in a text format– if so usually as Base64...

... if used with XML and/or text-based protocols i.e. HTTP headers/SMTP etc.

“binary” bytes are represented as one of 65 printable ASCII characters

tradeoff is 24 bits now represented by 32 bits

used for any binary data – not just encrypted data

XOR – A Simple Encryption Algorithm

See tutorial exercise.

Simply XOR the bits.

apply same key repeatedly to a block (several bytes at a time)

decryption algorithm is also XOR

XOR easily and efficiently implemented in hardware.

Susceptible to pattern recognition.

Very weak and not suitable for use on the web.

Symmetric key algorithm so requires some way of securely distributing the key value.

XOR is not used by itself in practice but is a key algorithmic component in many modern encryption algorithms e.g. AES.

the concepts are therefore worth studying…

XOR – One Time Pads

See tutorial exercise.

A full proof variation of previous example using XOR which is theoretically uncrackable.

Key must be as long as plaintext.

used once and not repeatedly applied to a block

Key must not be reused.

Key must be a true random number and not a pseudorandom one.

pseudorandom number generators use mathematical algorithms (completely computer-generated)

it is impossible to remove some patterns from the number sequence

true random number generators use an unpredictable physical phenomenon to generate numbers

for example atmospheric noise generated by natural atmospheric processes, primarily lightning discharges in thunderstorms

or radioactive decay

Example: AES-GCM

Used in TLS1.2

Transport Layer Security

establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts (Schannel)

Replaces RC4 in TLS1.2

AES-GCM now the recommended symmetric key algorithm

following recommendations to abandon RC4 in 2013

Symmetric keys with variable key lengths - 256 bits typical.

Symmetric algorithm.

AES can be used in a number of modes.

Galois/Counter Mode (GCM) is one mode.

very fast and particularly efficient for network use (TLS 1.2)

a counter identifies the block number

adds authentication (not considered here)

A stream block cipher.

a new value is used to encrypt a block of plaintext at a time

Encryption using AES and GCM

1. provide initialisation vector (IV) – random data

2. obtain next block sized array of plaintext, same size as the key

3. create “S-box” using AES (inputs are key and counter/IV combination)

4. use the S-box to XOR the current block of plaintext to give ciphertext block

5. increment the counter and goto 2.

Decryption is the same algorithm as it is symmetric.

Example: XML Encryption

Goal: ensure confidentiality of XML Messages.

Solution: obfuscate parts of an XML document, while maintaining a correct XML syntax.

Features:-

message security

end-to-end (confidentiality maintained across intermediaries)

full or partial encryption

flexibility: different parts of a message can be read by different parties using different keys

uses symmetric keys (AES or older 3DES)

Challenges and problems:-

is an encrypted XML document still XML?

W3C Recommendation, December 2002

Example: RSA

RSA name taken from the surnames of Ron Rivest, Adi Shamir, and Leonard Adleman for the algorithm they first described in 1977.

A public key algorithm still used today but key lengths have been largely increased!

typically 2048 bits or larger

note that key lengths have various tradeoffs

private keys should never be transmitted or shared

RSA used in digital signatures, SSL certificates and by TLS 1.2 in initial handshake.

Digital Signatures

Digital signatures provide a way of validating a document proving the integrity of its contents and origin. They provide guarantee of integrity of:- 

the document contents i.e. to prove to the recipient that the contents have not been tampered with by a third-party

the document at a later date i.e. so that the recipient can prove that he/she has the document in its original form

sender must have the corresponding private key

so provides a guarantee of document’s origin

They use public key encryption and hash algorithms.

Notice by itself this does not guarantee the origin’s identity.

only that they have the private key that signed the document

Digital signatures usually use public key encryption. Generically they are used thus:-

1. sender uses message to calculate message digest i.e. message checksum (this is also called a hash or message authentication code (MAC) and the algorithm used is a one-way hash algorithm e.g. SHA-2).

2. sender encrypts message digest (with an optional timestamp) with sender’s private key to form digital signature

3. sender sends message and digital signature

4. receiver decrypts digital signature with sender’s public key to recover message digest and timestamp

5. receiver recalculates message digest and compares against received one; if they are the same then message is authenticated.

The timestamp adds to the confidence that an opaque message has not been recorded and replayed at a later date.

It may rely on certification to provide confidence in the identity of the origin of the public key.

Security Tokens and Authentication

We may require additionally to confirm the identity of the message originator.

A security token can be signed to authenticate a claim made by the sender of the message e.g. their identity.

Signatures associated with tokens can be verified by the recipient to authenticate the identity of the sender.

Example: X.509 certificates (containing public keys) should be signed in order to provide authentication of the requester (client) of a service. (The requester has the corresponding private key).

X.509 Certificates

Part of X.500 directory service standards.

Defines framework for authentication services:-

defines public keys stored as certificates in a public directory

certificates are issued and signed by an entity called a certification authority (CA)

binds a server’s DNS domain name (or a user’s email address) to their public key with a digital signature

a third party receiving user’s certificate can check using CA’s public key

Symantec and Comodo are examples of CAs from which X.509 certificates can be purchased

Used by numerous protocols/applications: TLS/SSL Certificates (HTTPS), WS-Security etc.

Public Key Certificates

Certificates allow key exchange without real-time access to a CA.

a certificate binds identity to a public key.

contents signed by a trusted public key authority or CA.

can be verified by anyone who knows the CA’s public-key.

A CA provides its own root CA certificate containing its own public key.

these are no different from any other certificate but are self-signed.

Typically browsers and OSs have a pre-installed set of certificates including root CA certificates.

You can create a chain of certificates – chain of trust.

You can also create your own (free) certificates for software development purposes and you self-sign these.

X.509 Certificates

Certificates in general contain (and there are different types):-

version (1, 2, or 3)

serial number (unique within CA) identifying certificate

signature algorithm identifier

issuer X.500 name (CA)

period of validity (from - to dates)

subject X.500 name (name of owner, owner email address)

subject public key info (algorithm, parameters, public key)

issuer unique identifier (v2+)

subject unique identifier (v2+)

extension fields (v3)

signature (of hash of all fields in certificate and encrypted with issuing CA’s private key)

An "SSL Certificate" is a X.509 Certificate with Extended Key Usage: Server Authentication which adds:-

server DNS name

HTTPS layers HTTP over SSL/TLS.

HTTPS has exactly the same request-types, request and response headers as HTTP

What HTTPS provides is a secure, encrypted HTTP channel on TLS/SSL transparent to users.

however HTTPS only uses the TLS/SSL feature to authenticate the server to the client

client authentication is part of HTTP and is defined in rfc2617 (and has been extended from this).

in fact basic and digest authentication on the next few slides are used in both HTTP and HTTPS

HTTP Client Authentication

Defined in rfc2617

adds 2 new header fields

In general:-

1. browser/client attempts to request a page/access to resource

2. server responds with 401 Unauthorized and a WWW-uthenticate: header containing a challenge e.g. identifying the server and thereby asking for a username/password for it

3. browser/client prompts user for credentials, then re-sends the request with an Authorization: header containing a response to the challenge

Authenticated HTTP Interactions

HTTP Built-in Authentication

basic and digest as defined in rfc2617

Custom Token Authentication

any other way of using the same headers but as defined in another standard e.g. OAuth

also older NTLM from MS etc.

HTTP Built-in Authentication

rfc2617 defines:-

basic: the client sends the user name and password as unencrypted Base64 encoded text. It should only be used through a Schannel as the password can be easily captured and reused over plaintext communication.

digest: the client sends a hashed form (MD5) of details (including username & password) to the server. Although the password cannot be captured over HTTPS (or HTTP), it may be possible to replay requests using the hashed password so a challenge includes a nonce (one time use integer) which is also an input to the digest. Again Base64 is used as the encoding.

Authenticated HTTP Interactions

Basic

Authorization: Basic WxhZGRpbjpuIHNlc2FtZQ==

Base64 encoded username and password

Digest

Authorization: Digest uifREggSUOIHNlc2FtZQ==

Base64 encoded digest of data i.e. hash of: user name, password, nonce value, request method and requested URI

OAuth (Custom Token Authentication)

Authorization: Bearer ZZXTKskdjsdRhjhjsdjf==

Base64 encoded JWT