Application Layer Security

Agenda

• HTTPS (Hypertext Transfer Protocol over Secure Socket Layer)

• SSH (Secure Shell)

• E-mail Security: PGP and S/MIME

HTTPS (HYPERTEXT TRANSFER PROTOCOL OVER SECURE SOCKET LAYER)

HTTP (Hypertext Transfer Protocol) • HTTP provides a set of rules and standards that govern how

information is transmitted on the World Wide Web.

• Computers on the World Wide Web use the HyperText Transfer Protocol to talk with each other

• http://www. telkomuniversity.ac.id

• The first part of an address (URL) of a site on the Internet, signifying a document written in Hypertext Markup Language (HTML).

• HTTP is a client-server protocol by which two machines communicate using a reliable, connection-oriented transport service such as the TCP.

• A browser is an HTTP client because it sends requests to an HTTP server (Web server), which then sends responses back to the client

• An HTTP server is a program that sits listening on a machine's port for HTTP requests.

• The standard (and default) port for HTTP servers to listen on is 80, though they can use any port.

• HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used.” e.g.TCP.

How HTTP Works • HTTP Server is implemented by :

• Apache HTTP Server

• Microsoft IIS

• Jigsaw

• Zope etc.

• Each client-server transaction, whether a request or a response, consists of three main parts

• A response or request line

• Header information

• The body

HTTP Limitations

Security Concerns

• Privacy

• Anyone can see content

• Integrity

• Someone might alter content. HTTP is insecure since no encryption methods are used. Hence is subject to man in the middle and eavesdropping of sensitive information.

• Authentication

• Not clear who you are talking with. Authentication is sent in the clear — Anyone who intercepts the request can determine the username and password being used.

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) • SSL acts like a sub layer under

regular HTTP application layering.

• HTTPS encrypts an HTTP message prior to transmission and decrypts a message upon arrival.

• HTTPS by default uses port 443 as opposed to the standard HTTP port of 80.

HTTPS

• URL's beginning with HTTPS indicate that the connection between client and browser is encrypted using SSL

e.g.: https://login.yahoo.com/config/login_verify2?&.src=ym

• SSL transactions are negotiated by means of a key based encryption algorithm between the client and the server, this key is usually either 40 or 128 bits in strength (the higher the number of bits the more secure the transaction).

HTTPS

• Need SSL if… • you have an online store or accept online orders and credit cards • you offer a login or sign in on your site • you process sensitive data such as address, birth date, license, or ID numbers • you need to comply with privacy and security requirements

• Certification Authority (CA) is an entity that issues digital certificates for

use by other parties. It is an example of a trusted third party. e.g. VeriSign, Thwate, Geotrust etc

• Ability to connect to server via HTTP secure consists of:

• Generating key • Generating certificate signing request • Generating self signed certificate • Certificate Authority signed certificate • Configuring web server.

SSL Diagram • When any modern browser is installed, it is sent

with several CA issuer certificates. These issuer certificates contain a public key for the issuer, among other information.

• When a web designer decides to use SSL he needs to purchase a certificate that is signed using the CA's private key.

• The web browser starts a connection to an HTTPS site. Along with this request the client sends all supported encryption schemes.

• As a response to the browser's connection request, the Server sends a copy of the certificate from step 2. Along with this transmission is the server's answer to the encryption negotiation.

• Once a certificate is downloaded, the signature of the certificate (that was signed using the CA's private key) is checked using the CA's public key (installed in the browser in step 1.

• The connection succeeds, the client can now download and upload to the web site with the security of encryption.

SSL Handshake • A HTTP-based SSL connection is always initiated by the client using a URL

starting with https:// instead of with http://.

• At the beginning of an SSL session, an SSL handshake is performed

• This handshake produces the cryptographic parameters of the session.

How SSL Overcomes HTTP Security Concerns • Secure Sockets Layer technology protects your Web site and makes

it easy for your Web site visitors to trust you in three essential ways:

• Privacy

• An SSL Certificate enables encryption of sensitive information during online transactions.

• Integrity.

• A Certificate Authority verifies the identity of the certificate owner when it is issued.

• Authentication.

• Each SSL Certificate contains unique, authenticated information about the certificate owner.

SSH (SECURE SHELL)

What is SSH?

• “SSH is a protocol for secure remote login and other secure network services over an insecure network.” – RFC 4251

• Secure channel between two computers

• Provides data confidentiality and integrity

• Many uses other than remote shell

15

SSH

• Uses cryptographic algorithms to

• Authenticate both ends of the connection

• Encrypt all transmitted data

• Protect data integrity

• Validate values returned by services such as DNS or network protocols (such as TCP)

Components of SSH

Port forwarding

SSH packet format

Layering of SSH Protocols

• Transport Layer Protocol • Provides server authentication, confidentiality, and integrity

• User Authentication Protocol • Authenticates the client-side user to the server

• Connection Protocol • Multiplexes the tunnel into logical channels

• New protocols can coexist with the existing ones

20

Transport-level encryption

• Every transmitted packet starts with random padding, followed by (optionally compressed) header and data

• The entire packet is encrypted using a suitable algorithm

• Packet type and data fields can be compressed with gzip before encryption

• 1/3 of original size

Transport Layer Protocol

• Public-key host authentication • Lets the client know the correct server is on the other end

• DSS or RSA, raw or through OpenPGP

• Strong symmetric encryption • Uses Diffie-Hellman algorithm for secure key exchange

• Many ciphers are supported: 3des, blowfish, twofish, aes, etc., most with multiple key sizes

• New keys generated every 1 GB or 1 hour

• Data integrity via MACs (message authentication codes) • SHA-1 and MD5 are supported 22

What is HMAC-SHA? (I)

• HMAC:

• Hash-based Message Authentication Code

• Uses a cryptographic hash function

• Any change to the hashed data will (with very high probability) change the hash value

What is HMAC-SHA? (II)

• SHA: • Secure Hash Algorithm

• Four different algorithms: SHA-0, SHA-1, SHA-2, and SHA-3

• SHA-1 • Most widely used

• Fixes a flaw in SHA-0

• Produces a 160-bit "digest"

User Authentication Protocol

• Multiple authentication methods

• public-key, password, host-based

• Extensible

• Server tells client which methods can be used, client picks the most convenient

• Provides a single authenticated channel to the connection protocol

25

Connection Protocol

• Provides multiple channels:

• interactive login sessions

• remote execution of commands

• forwarded X11 connections

• forwarded TCP/IP connections

• All channels are multiplexed into a single encryption tunnel

26

SSH login protocol

• Works on top of the packet-level protocol

• Step 1: The client opens a connection to the server

• Step 2: Server sends

• Its public RSA host key

• Another public RSA key (``server key'') that changes every hour

SSH login protocol

The client compares the received host key against its own database of known host keys,

Can decide to

• Reject keys coming from unknown hosts

• Accept them and store them in its database

SSH login protocol

• Step 3: The client • Generates a 256 bit random number using a cryptographically strong

RNG (session key)

• Picks an encryption algorithm among those supported by the server

• Encrypts the session key with RSA using both the host key and the server key

• Sends the encrypted key to the server

The server key

• Changed every hour

• Used to make decrypting recorded historic traffic impossible after the server key has been changed when the host key becomes compromised

• Normally a 768 bit RSA key

• Host key is 1024 bits

SSH login protocol

• Step 4: Server

• Recovers the session key

• Sends an encrypted confirmation to the client

• Shows client that it holds the proper private keys

Client and server can start using transport-level encryption and integrity protection

SSH login protocol

• Step 5: User starts authentication procedure

• First request includes the user login name

• Server replies with either

• success no further authentication is needed

• failure further authentication is required

E-MAIL SECURITY: PGP AND S/MIME

What is PGP?

• PGP - Pretty Good Privacy

• general purpose application to protect (encrypt and/or sign) files

• can be used to protect e-mail messages

• can be used by corporations as well as individuals

• based on strong cryptographic algorithms (IDEA, RSA, SHA-1)

• available free of charge at http://www.pgpi.org

• first version developed by Phil Zimmermann

• PGP is now on an Internet standards track (RFC 3156)

PGP services

• messages

• authentication

• confidentiality

• compression

• e-mail compatibility

• segmentation and reassembly

• key management

• generation, distribution, and revocation of public/private keys

• generation and transport of session keys and IVs

Message authentication • based on digital signatures

• supported algorithms: RSA/SHA and DSS/SHA

hash hash enc enc

hash hash dec dec compare compare

accept / reject

m h s

Ksnd-1

Ksnd

m h s h

sen

der

re

ceiv

er

Message confidentiality • symmetric key encryption in CFB mode with a random session key

and IV

• session key and IV is encrypted with the public key of the receiver

• supported algorithms: • symmetric: CAST, IDEA, 3DES

• asymmetric: RSA, ElGamal

prng prng

s.enc s.enc

m Krcv

sen

der

a.enc a.enc k, iv

{m}k

{k, iv}Krcv

Compression

• applied after the signature

• enough to store clear message and signature for later verification

• it would be possible to dynamically compress messages before signature verification, but …

• then all PGP implementations should use the same compression algorithm

• however, different PGP versions use slightly different compression algorithms

• applied before encryption

• compression reduces redundancy makes cryptanalysis harder

• supported algorithm: ZIP

E-mail compatibility • encrypted messages and signatures may contain arbitrary octets

• most e-mail systems support only ASCII characters

• PGP converts an arbitrary binary stream into a stream of printable ASCII characters

• radix 64 conversion: 3 8-bit blocks 4 6-bit blocks

0 7 0 7 0 7

0 5 0 5 0 5 0 5

character

encoding

6-bit

value

52 0

… …

61 9

62 +

63 /

(pad) =

0 A

… ...

25 Z

26 a

… …

51 z

character

encoding

6-bit

value

Combining services X := file X := file

signature? signature?

compress

X := Z(X)

compress

X := Z(X)

encryption? encryption?

radix 64

X := R64(X)

radix 64

X := R64(X)

generate signature

X := s(X) || X

generate signature

X := s(X) || X

generate envelop

X := {k}Krcv || {X}k

generate envelop

X := {k}Krcv || {X}k

yes

yes

no

no

PGP message format session key

component

signature

message

key ID of Krcv

session key k

timestamp

key ID of Ksnd

leading two octets of hash

hash

filename

timestamp

data

{ } K

rcv

{ } K

snd-1

{ } k

ZIP

R64

Key IDs

• a user may have several public key – private key pairs

• which private key to use to decrypt the session key?

• which public key to use to verify a signature?

• transmitting the whole public key would be wasteful

• associating a random ID to a public key would result in management burden

• PGP key ID: least significant 64 bits of the public key

• unique within a user with very high probability

Random number generation

• true random numbers

• used to generate public key – private key pairs

• provide the initial seed for the pseudo-random number generator (PRNG)

• provide additional input during pseudo-random number generation

• pseudo-random numbers

• used to generate session keys and IVs

True random numbers

• PGP maintains a 256-byte buffer of random bits

• each time PGP expects a keystroke from the user, it records

• the time when it starts waiting (32 bits)

• the time when the key was pressed (32 bits)

• the value of the key stroke (8 bits)

• the recorded information is used to generate a key

• the generated key is used to encrypt the current value of the random-bit buffer

Pseudo-random numbers

• based on the ANSI X9.17 PRNG standard

3DES 3DES

3DES 3DES

3DES 3DES

+

+

DTi

Vi

Vi+1

K1, K2

Ri

Pseudo-random numbers E E

E E

E E +

+ E E

E E +

+ E E

E E +

+

+ + +

dtbuf

rseed

rseed’

IV[0..7] K[8..15] K[0..7]

true random bits

CAST-128 is used instead of 3DES with key rkey

Pseudo-random numbers

• dtbuf[0..3] = current time, dtbuf[4..7] = 0

• pre-wash • take the hash of the message

• this has already been generated if the message is being signed

• otherwise the first 4K of the message is hashed

• use the result as a key, use a null IV, and encrypt (rkey, rseed)previous in CFB mode • if (rkey, rseed)previous is empty, it is filled up with true random bits

• set (rkey, rseed)current to the result of the encryption

• post-wash • generate 24 more bytes as before but without XORing in true

random bytes

• encrypt the result in CFB mode using K and IV

• set (rkey, rseed)previous to the result of the encryption

Private-key ring • used to store the public key – private key pairs owned by a given

user

• essentially a table, where each row contains the following entries:

• timestamp

• key ID (indexed)

• public key

• encrypted private key

• user ID (indexed)

enc enc passphrase hash hash

private key

encrypted private key

Public-key ring

• used to store public keys of other users

• a table, where each row contains the following entries:

• timestamp

• key ID (indexed)

• public key

• user ID (indexed)

• owner trust

• signature(s)

• signature trust(s)

• key legitimacy

Trust management

• owner trust • assigned by the user

• possible values: • unknown user

• usually not trusted to sign

• usually trusted to sign

• always trusted to sign

• ultimately trusted (own key, present in private key ring)

• signature trust • assigned by the PGP system

• if the corresponding public key is already in the public-key ring, then its owner trust entry is copied into signature trust

• otherwise, signature trust is set to unknown user

Trust management

• key legitimacy • computed by the PGP system

• if at least one signature trust is ultimate, then the key legitimacy is 1 (complete)

• otherwise, a weighted sum of the signature trust values is computed • always trusted signatures has a weight of 1/X

• usually trusted signatures has a weight of 1/Y

• X, Y are user-configurable parameters

• example: X=2, Y=4 • 1 ultimately trusted, or

• 2 always trusted, or

• 1 always trusted and 2 usually trusted, or

• 4 usually trusted signatures are needed to obtain full legitimacy

Example – key legitimacy X = 1, Y = 2

user

A

B

C

D

E

F

G H

I

J

K

M L

untrusted / usually untrusted

usually trusted

always trusted

ultimately trusted (you)

signature

legitimate

Public-key revocation

• why to revoke a public key? • suspected to be compromised (private key got known by

someone)

• re-keying

• the owner issues a revocation certificate … • has a similar format to normal public-key certificates

• contains the public key to be revoked

• signed with the corresponding private key

• and disseminates it as widely and quickly as possible

• if a key is compromised: • e.g., Bob knows the private key of Alice

• Bob can issue a revocation certificate to revoke the public key of Alice

• even better for Alice

What is S/MIME?

• Secure / Multipurpose Internet Mail Extension

• a security enhancement to MIME

• provides similar services to PGP

• based on technology from RSA Security

• industry standard for commercial and organizational use

• RFC 2630, 2632, 2633

RFC 822

• defines a format for text messages to be sent using e-mail

• Internet standard

• structure of RFC 822 compliant messages • header lines (e.g., from: …, to: …, cc: …)

• blank line

• body (the text to be sent)

• example

Date: Tue, 16 Jan 1998 10:37:17 (EST)

From: “Levente Buttyan” <buttyan@hit.bme.hu>

Subject: Test

To: afriend@otherhost.bme.hu

Blablabla

Problems with RFC 822 and SMTP • executable files must be converted into ASCII

• various schemes exist (e.g., Unix UUencode)

• a standard is needed

• text data that includes special characters (e.g., Hungarian text)

• some servers

• reject messages over a certain size

• delete, add, or reorder CR and LF characters

• truncate or wrap lines longer than 76 characters

• remove trailing white space (tabs and spaces)

• pad lines in a message to the same length

• convert tab characters into multiple spaces

MIME

• defines new message header fields

• defines a number of content formats (standardizing representation of multimedia contents)

• defines transfer encodings that protects the content from alteration by the mail system

MIME - New header fields

• MIME-Version

• Content-Type

• describes the data contained in the body

• receiving agent can pick an appropriate method to represent the content

• Content-Transfer-Encoding

• indicates the type of the transformation that has been used to represent the body of the message

• Content-ID

• Content-Description

• description of the object in the body of the message

• useful when content is not readable (e.g., audio data)

MIME – Content types and subtypes • text/plain, text/enriched

• image/jpeg, image/gif

• video/mpeg

• audio/basic

• application/postscript, application/octet-stream

• multipart/mixed, multipart/parallel, multipart/alternative, multipart/digest (each part is message/rfc822)

• message/rfc822, message/partial, message/external-body

MIME – Transfer encodings

• 7bit • short lines of ASCII characters

• 8bit • short lines of non-ASCII characters

• binary • non-ASCII characters

• lines are not necessarily short

• quoted-printable • non-ASCII characters are converted into hexa numbers (e.g., =EF)

• base64 (radix 64) • 3 8-bit blocks into 4 6-bit blocks

• x-token • non-standard encoding

MIME – Example MIME-Version: 1.0 From: Nathaniel Borenstein <nsb@nsb.fv.com> To: Ned Freed <ned@innosoft.com> Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1 Content-type: text/plain; charset=US-ASCII … Some text … --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64 ... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64 ... base64-encoded image data goes here ... --unique-boundary-2--

MIME – Example cont’d --unique-boundary-1 Content-type: text/enriched This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller> Isn’t it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... Additional text in ISO-8859-1 goes here ... --unique-boundary-1--

S/MIME services

• enveloped data (application/pkcs7-mime; smime-type = enveloped-data)

• standard digital envelop

• signed data (application/pkcs7-mime; smime-type = signed-data)

• standard digital signature (“hash and sign”)

• content + signature is encoded using base64 encoding

• clear-signed data (multipart/signed)

• standard digital signature

• only the signature is encoded using base64

• recipient without S/MIME capability can read the message but cannot verify the signature

• signed and enveloped data

• signed and encrypted entities may be nested in any order

Cryptographic algorithms

• message digest • must: SHA-1 • should (receiver): MD5 (backward compatibility)

• digital signature • must: DSS • should: RSA

• asymmetric-key encryption • must: ElGamal • should: RSA

• symmetric-key encryption • sender:

• should: 3DES, RC2/40

• receiver: • must: 3DES • should: RC2/40

Securing a MIME entity

• MIME entity is prepared according to the normal rules for MIME message preparation

• prepared MIME entity is processed by S/MIME to produce a PKCS object

• the PKCS object is treated as message content and wrapped in MIME

PKCS7 “signed data”

Version

(Set of) Digest Algorithms

Content Info

Set of certificates

Set of CRLs

Signer Info

Version

Signer ID (issuer and ser. no.)

Digest Algorithm

Authenticated Attributes

Digest Encryption Alg.

Encrypted digest (signature)

Content type

Content

PKCS7 “enveloped data”

Version

Encrypted Content Info

Recipient Info

Version

Recipient ID (issuer and s.no.)

Key Encryption Algorithm

Encrypted Key

Content Encryption Alg.

Content type

Encrypted Content

Originator Info

Enveloped data – Example

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

Clear-signed data – Example Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42--

Key management • S/MIME certificates are X.509 conformant

• key management scheme is between strict certification hierarchy and PGP’s web of trust • certificates are signed by certification authorities (CA)

• key authentication is based on chain of certificates

• users/managers are responsible to configure their clients with a list of trusted root keys

K