PART 1:o Encryption

• DES• AES

o RPC SEC Using GSS API• Instructor Request

PART 2:o Public Key Infrastructureo Digital Signatureo Secure Sockets Layer

Developed in the early 1970’s NSA involved in design Based on IBM’s Lucifer Feistel Cipher Selected in 1976 as an official Federal Information

Processing Standard for the US 64 bit blocks 56 bit key 16 rounds

Plaintext encrypted in blocks Encryption consists of multiple rounds Each round uses output of previous round as

input Key is used in all round

Type of Block Cipher

Right halfLeft half

KeyKey

New R-halfNew L-half

function

64 bit block of input 64 bit key

o Only 56 bits are usedo Every 8th bit ignored

56 bit key is manipulated to obtain 16 different 48 bit ‘stage keys’

Stage keys are used during each round of encryption

The 64 bit stage key is permutated Only 56 bits are used

Example 64 bit KEY = CSE-8343o 01000011 01010011 01000101 00101101 00111000 00110011 00110100

00110011

Permutated 56 bit Keyo 0000000 0000001 1111111 0001111 1010001 1010011 0000011

0000010

Split the permutated key into halveso 0000000 0000001 1111111 0001111 o 1010001 1010011 0000011 0000010

For each round (1-16), perform the following left shifts on both halves:

Round 1o 0000000000001111111100011110 o 0100011010011000001100000101

Round 2o 0000000000011111111000111100 o 1000110100110000011000001010

Convert each round’s 56 bit key to a permutated 48 bit key using the following permutation table:

16 Rounds are required

Only Rounds 1 and 2 are shown here

Message broken into 64 bit blocksI hope we get an A!

0100100100100000011010000110111101110000011001010010000001110111

1011110110010000101010001010100100000000111111100000110110001000

Permutated Message:

Permutated message broken into L and RL = 10111101100100001010100010101001

R = 00000000111111100000110110001000

Right half of message fed into F function.o Expands R (32 bits expanded to 48 bits)o XOR round key (48 bits) with Expanded Ro Run result through the S-BOX stepo Permutate the S-BOX result

Result become next round’s Left half

Output of F Function XOR with Left half of messageo Output of XOR becomes next round’s Right Half

Expand 32 bits to 48 bits using the following box

After Expand Function and XOR with Key we have 48 bits.

Divide 48 bits into 8 sets of 6 bits.o xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx

xxxxxx xxxxxx

Each set of 6 bits is used to lookup new value in Substitution box. Result is new 32 bits.o Example, 100110 gets converted to 1110 (Decimal 14)

• 100110 = Row 2• 100100 = Column 2

Permutate the 32 bit result of the Substitution Box

Repeat the steps for all 16 rounds. Each rounds uses new round key. After 16th step completes, permutate

the final result.

Decryption of a DES cipher is the same steps, in reverse

DES relies on Substitution Box for security NO BACK DOOR REVEALED AFTER 40 YEARS Only way to attack DES is by brute force ONE to ONE mapping of Plaintext to Ciphertext On average, a brute force of DES will take:

o 2^(55) = 36,028,797,018,963,968 attempts 3DES created to increase brute force complexity

o Uses back to back to back DES encryptiono 168 bit key is used (56 bits per encryption)

3DES is slow, requires 3x the work as DES 3DES only uses 64 bit blocks

The National Institute of Standards and Technology requested new algorithmo Must be better or at least equal security of 3DESo Must be more efficient than 3DESo Must accept variable key lengths

Rijndael algorithm selected as new AES

Block Ciphero 128 bit blocks are used

NOT a Feistel structure Uses keys of 128, 192 or 256 bit

o 128 bit key uses 10 rounds per 128 bit blocko 192 bit key uses 12 rounds per 128 bit blocko 256 bit key uses 14 rounds per 128 bit block

Add Round Key

Mix Columns

Shift Rows

Add Round Key

Substitute Bytes

Add round key

Shift Rows

Substitute Bytes

Add round key

Substitute Bytes

Shift Rows

Mix Columns

Expand Key

.

.

.

w[0,3]

w[4,7]

w[36,39]

w[40,43]

Plaintext

Ciphertext

Rou

nd 9

Rou

nd 1

0R

ound

1

Key Expansion Algorithm:o Takes 128 bit (16 byte) keyo Produces 44 words (32 bit

each)

round 0 :o Add Round Key.

rounds 1-9 :o S-Box; Shift Rows; Mix

Columns; Add Round Key. round 10 :

o S-Box; Shift Rows; Add Round Key.

KeyExpansion(byte key[16], word w[44]){

word temp;for (i = 0; i < 4; i++)

w[i] = (key[4*i], key[4*i+1], key[4*i+3], key[4*i+3]);

for (i = 4; i < 44; i++)}

temp = w[i-1];if ( i mod 4 = 0 )

temp = SubWord(RotWord(temp)) XOR Rcon[i/4];w[i] = w[i-4] XOR temp;

}}

RotWord performs a one byte circular left shift on a word. For example:

RotWord[b0,b1,b2,b3] = [b1,b2,b3,b0]

SubWord performs a byte substitution on each byte of input word using an S-box.

SubWord(RotWord(temp)) is XORed with Rcon[j] – the round constant.

Round Constant is different for each round (j)o Rcon[j] = (RC[j],0,0,0)

• where RC[1] = 1, RC[j] = 2 * RC[j-1]

For each 8 bit byte:o C= Inverse of byteo Output S = (MC) XOR B

• M is S box matrix• B is implementation

dependent, usually decimal 99 (1100011)

Add Round Key

Mix Columns

Shift Rows

Add Round Key

Substitute Bytes

Add round key

Shift Rows

Substitute Bytes

Add round key

Substitute Bytes

Shift Rows

Mix Columns

Expand Key

.

.

.

w[0,3]

w[4,7]

w[36,39]

w[40,43]

Plaintext

Ciphertext

Rou

nd 9

Rou

nd 1

0R

ound

1

For each 8 byte column in a 4x4 byte matrix, substitute cells as below:

Add Round Key

Mix Columns

Shift Rows

Add Round Key

Substitute Bytes

Add round key

Shift Rows

Substitute Bytes

Add round key

Substitute Bytes

Shift Rows

Mix Columns

Expand Key

.

.

.

w[0,3]

w[4,7]

w[36,39]

w[40,43]

Plaintext

Ciphertext

Rou

nd 9

Rou

nd 1

0R

ound

1

For each 4 byte column C of each 4x4 byte matrix:

Add Round Key

Mix Columns

Shift Rows

Add Round Key

Substitute Bytes

Add round key

Shift Rows

Substitute Bytes

Add round key

Substitute Bytes

Shift Rows

Mix Columns

Expand Key

.

.

.

w[0,3]

w[4,7]

w[36,39]

w[40,43]

Plaintext

Ciphertext

Rou

nd 9

Rou

nd 1

0R

ound

1

For resulting 128 bit output, XOR with 128 bit round key word w[x, x+3]

Add Round Key

Mix Columns

Shift Rows

Add Round Key

Substitute Bytes

Add round key

Shift Rows

Substitute Bytes

Add round key

Substitute Bytes

Shift Rows

Mix Columns

Expand Key

.

.

.

w[0,3]

w[4,7]

w[36,39]

w[40,43]

Plaintext

Ciphertext

Rou

nd 9

Rou

nd 1

0R

ound

1

Inverse mix cols

Add round key

Inverse sub bytes

Inverse shift rows

Add round key

Inverse sub bytes

Inverse shift rows

Inverse mix cols

Add round key

Inverse sub bytes

Inverse shift rows

Add round key

.

.

.

w[0,3]

w[4,7]

w[36,39]

w[40,43]

Ciphertext

Rou

nd 1

Rou

nd 9

Rou

nd 1

0

Expand Key

Decryption is not identical to encryptiono See structure to the right

AES is fast and secureo Brute force of AES 128 bit

would take on average 2^(127) = 170,141,183,460,469,000,000,000,000,000,000,000,000 attempts!

• Would require 30 gigawatts of power for one year.

o 256 bit AES would take a device that could check a billion billion 2^(18) AES keys per second about 3x10^(51) years!!

Used by a client to execute a procedure on a server.o Example – Remote File Systems, inter / intra process

communication.

Request Response

Proc. Input args Results

lookup dirfh, name status, fhandle, fattr

read fhandle, offset, count status, fattr, data

create dirfh, name, fattr status, fhandle, fattr

write fhandle, offset, count, data status, fattr

Source: Diagram from Pei - CS244B-DFS-1.ppt

Generic Security Services Application Program Interfaceo Programming interface for C and Javao Used by NSF Version 4 to provide confidentiality and

integrityo Does not provide securityo Provides an interface to security implementationso Based around the idea of tokens, usually using Kerberoso Used by Client / Server type of applications

GSS API defines ~ 50 procedures

o GSS_Acquire_cred - obtains the user's identity proof, often a secret cryptographic key

o GSS_Import_name - converts a username or hostname into a form that identifies a security entity

o GSS_Init_sec_context - generates a client token to send to the server, usually a challenge

o GSS_Accept_sec_context - processes a token from GSS_Init_sec_context and can generate a response token to return

o GSS_Seal - cryptographically signs and optionally encrypts the specified input_message

o GSS_Unseal - converts a previously sealed message back to a usable form, verifying the embedded signature

o GSS_Sign - generates a cryptographic signature and places the signature in a token for transfer to the peer application.

// Allows an application to acquire a handle for a pre-existing// credential by name.

OM_uint32 gss_acquire_cred ( OM_uint32 * minor_status, gss_name_t desired_name, // Name of principle whose credentials should be aquired OM_uint32 time_req, // Number of seconds credentials should remain valid gss_OID_set desired_mechs, // Set of secuirty mechanisms to use, or GSS_C_NULL_OID_SET int cred_usage, // Option enum specifying when to use credentials gss_cred_id_t * output_cred_handle, // The returned credential handle gss_OID_set * actual_mechs, // The security mechanisms that the credential is valid for OM_int32 * time_rec) // Number of seconds credential will be valid for

// Converts a printable name to internal form.

OM_uint32 gss_import_name ( OM_uint32 * minor_status, // Mechanism specific status code gss_buffer_t input_name_buffer, // Buffer containing printable name to convert gss_OID input_name_type, // Object Id specifying type of printable name. gss_name_t * output_name) // returned name in internal form

// generates a client token to send to the server

OM_uint32 gss_init_sec_context ( OM_uint32 * minor_status, gss_cred_id_t claimant_cred_handle, // handle for credentials claimed gss_ctx_id_t * context_handle, // context handle for new context gss_name_t target_name, // Name of target gss_OID mech_type, // Object ID of desired security mechanism int req_flags, // Four flags used to control credential handling int time_req, // Number of seconds for context to remain valid gss_channel_bindings_t input_chan_bindings, // Allows application to securely bind channel gss_buffer_t input_token // Token received from peer application gss_OID * actual_mech_type, // actual mechanism used gss_buffer_t output_token, // token to be sent to peer application int * ret_flags, // contains six independent flags descirbing credential options used OM_uint32 * time_rec ) // number of seconds for which the context will remain valid

// Allows a remotely initiated security context between the application// and a remote peer to be established.

OM_uint32 gss_accept_sec_context ( OM_uint32 * minor_status, // gss_ctx_id_t * context_handle, // context handle for new context gss_cred_id_t verifier_cred_handle, // credential handle claimed by context gss_buffer_t input_token_buffer // token obtained from remote application gss_channel_bindings_t input_chan_bindings, // allows application to securely bind channel gss_name_t * src_name, // authenticated name of context initiator gss_OID * mech_type, // security mechanism used gss_buffer_t output_token, // token to be passed to peer application int * ret_flags, // contains six independent flags descirbing credential options used OM_uint32 * time_rec, // number of seconds for which the context remains valid gss_cred_id_t * delegated_cred_handle) // credential handle for credentials received from context initiator

// cryptographically signs and optionally encrypts the specified input_message

OM_uint32 gss_seal ( OM_uint32 * minor_status, // implementation specific status code gss_ctx_id_t context_handle, // identifies the context on which the message will be sent int conf_req_flag, // flag indicating confidentiality and integrity protection requested int qop_req // specifies required quality of protection gss_buffer_t input_message_buffer, // message to be sealed int * conf_state, // confidentiality indicator flag gss_buffer_t output_message_buffer) // buffer to receive sealed message

// converts a previously sealed message back to a usable form, verifying the embedded signature

OM_uint32 gss_unseal ( OM_uint32 * minor_status, // implementation specific status code gss_ctx_id_t context_handle, // identifies the context on which the message arrived gss_buffer_t input_message_buffer, // sealed message gss_buffer_t output_message_buffer, // buffer to receive unsealed message int * conf_state, // flag indicating confidentiality and / or integrity protection int * qop_state) // quality of protection gained from signature

// generates a cryptographic signature and places the signature in a token for transfer to the peer application.

OM_uint32 gss_sign ( OM_uint32 * minor_status, // implementation specific status code gss_ctx_id_t context_handle, // identifies the context on which the message will be sent int qop_req, // specifies requested quality of protection gss_buffer_t message_buffer, // message to be signed gss_buffer_t msg_token) // buffer to receive token

(Client) (Server)

Kerberos Kerberos

GSS_Acquire_credGSS_Import_name

GSS_Acquire_credGSS_Import_name

(Client)(Server)

Kerberos Kerberos

GSS_Init_sec_context GSS_Accept_sec_context

challenge

response

(Client)(Server)

Kerberos Kerberos

RPC (mount)

response

GSS_SealGSS_Unseal

RFC 2822 (Internet Security Glossary) defines PKI as the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography.

Principal objective of PKI is to enable secure, convenient, and efficient acquisition of public keys.

IETF Public Key Infrastructure X.509 (PKIX) working group has set up a model based on PKIX that is suitable for deploying a certificate-based architecture on the Internet.

End entity - Subject field of public key certificate that denotes end users, devices, servers, routers etc

Certification Authority (CA)- Issuer of certificates and Certificate Revocation Lists (CRL)

Registration Authority (RA)- Optional component that performs administrative functions such as end entity registration. CA could also do this.

CRL Issuer- Optional component that CA can delegate to publish CRL

Repository-Method and storage of certificates and CRL so that they can be retrieved by end entity.

Asymmetric encryption is a form of cryptosystem in which encryption and decryption are performed using different keys :

Public KeyPrivate key

Asymmetric encryption transforms plaintext into ciphertext using one of the two keys and an encryption algorithm. Using the paired key and a decryption algorithm, plaintext is recovered from ciphertext

Most widely used Public-key cryptosystem is RSA. Difficulty of attacking RSA is based on difficulty of finding prime factors of a composite number. RSA is computationally complex as well.

Symmetric cryptosystems use the same key for encryption and decryption. The key is called secret key or shared secret key used by sender and receiver.

Most widely used symmetric cryptographic algorithm is Data Encryption Standard(DES)

Conventional Encryption (Symmetric)

Public key Encryption (Asymmetric)

Needed to Work:1.Same algorithm with same key used for encryption and decryption2.Sender and Receiver must share the algorithm and key

Needed for Security:1.Key must be kept secret2.Must be impossible or at least impractical to decipher a message if no other info available3.Knowledge of algorithm plus samples of ciphertext must be insufficient to determine the key

Needed to Work:1.One algorithm used for encryption and decryption with a pair of keys, one for encryption and one for decryption2.Sender and Receiver must each have one of the matched pair of keys (not the same one)

Needed for Security:1.One of the two keys must be secret2.Must be impossible or at least impractical to decipher a message if no other info available3.Knowledge of algorithm plus one of the keys plus samples of ciphertext must be insufficient to determine the other key

Message Authentication is achieved when both sender and receiver are able to authenticate each other

Message Integrity means that message is protected against surreptitious modification

Message Confidentiality means that message cannot be intercepted and read by eavesdroppers. It is established by encrypting the message

Non-repudiation: Prevents sender/receiver from denying a legitimate transmission that occured

Availability: Communication channel to be available. Protect against Denial of Service attack

All of the above are to work together in a secure channel of communication

Digital Signature Sender signs a message with its private key. Signing

achieved by cryptographic algorithm applied to message or to a small block of data that is a function of the message

Key Exchange Sender and Receiver co-operate to exchange a

Session Key. Different approaches possible involving private keys of both parties

Encryption and Decryption Sender encrypts the message with receiver’s public

key.

Example of Key Exchange with Public key cryptosystem:Diffie-Hellman Key ExchangeProtocol works as follows: A and B want to establish a shared secret key They agree on two large numbers n and g that can be made

public A picks a large random number x which is secret (private key) B picks a large random number y which is secret (private key) A sends mod n (public key) to B, along with n and g B receives message and calculates which equals B sends mod n (public key) to A A computes which equals Now A and B have a shared secret key :

xgyx ng )mod(

ng xy modyg

xy ng )mod(

ng xy mod

ng xy mod

Authenticated Key distribution of Public-key done via Public-key certificates

Certificate consists of public key together with a string identifying the entity to which that key is associated. Entity could be user/host/other device.

Public key and identifier have been placed together and signed by Certification Authority (CA)

Certificates can be revoked by the CA regularly publishing Certificate Revocation List (CRL)

Certificate’s lifetime can also be restricted by CA Client has to check validity of certificate by

checking CRL or contact CA

Certificates

Sequence of X.509 certificateso Server’s, CA’s, …

X.509 Certificate associates public key with identity

Certification Authority (CA) creates certificateo Adheres to policies and verifies identityo Signs certificate

User of Certificate must ensure it is valid

Validating a Certificate

Must recognize accepted CA in certificate chaino One CA may issue certificate for another CA

Must verify that certificate has not been revokedo CA publishes Certificate Revocation List (CRL)

Hierarchical model of trusto Chain of partial trust ending in one “fully trusted”

entity Identifier associated with the key pair

o Unique distinguished name within the namespace Private-key insecurity

o Has to protect the private key Technical and Implementation difficulties

o Assumption of global namespaceo Difficulty in detecting key compromiseo Inefficient revocation

Limited assurance provided in reality

o CA’s generally protected in case of failure

o What certificate assures (usually)• A particular message was generated by an entity that

had available to it a particular private key; and

• CA that provided the certificate has, at some time in the past, believed that that private key was associated with a particular entity.

• CA that provided the certificate has, at some time in the past, believed that the entity had some kind of right to use that identifier, or had used that identifier in the past

• CA that provided the certificate has, at some time in the past, believed that the entity had access to the appropriate private key.

o What it does not ensure• Private key was originally available to other entities as

well as the entity to which it claims to be 'bound';• Private key is now available to other entities as well as

the entity to which it claims to be 'bound';• Private key invocation that gave rise to a particular

message was performed by the entity; and• Private key invocation that gave rise to a particular

message was performed with the entity's free and informed consent.

Privacy invasivenesso Just to communicate to your friend securely, you may need

to reveal too much information to a third party.

Weakness: o In order to have trust in the party you are transacting with,

you are expected to have trust in organizations you have no relationship with at all

Minimal Use of Identifiers Minimal Registration Requirements Mechanisms for Persistent Anonymity Value Authentication without Identity Attribute Authentication without Identity Recourse in case of violation

A digital signature is an authentication mechanism that enables the creator of message to attach code that acts as a signature.

Typically signature is formed by taking the hash of a message and encrypting the message with the creator’s private key

Signature guarantees the source and integrity of the message

Digital Signature Standard(DSS) is a NIST( National Institute of Standards & Technology) standard that uses Secure Hash Algorithm (SHA)

Properties of Digital Signatures Must verify the author, and date and time of

signature Must authenticate the contents at the time of

signature Must be verifiable by third party to resolve

dispute

Types of Attacks and Forgeries: A denotes the original user and C the attacker Key only attack – C knows only A’s public key Known message attack- C has access to a set of

messages and their signatures

Generic chosen message attack- Independent of A’s public key, C chooses a list of messages and obtains A’s valid signatures from the messages. Same attack can be used by C against anyone, therefore generic.

Directed chosen message attack- C knows A’s public key. It chooses a list of messages from A.

Outcomes Total break – C determines A’s private key Universal Forgery- C finds an efficient signing

algorithm that provides an equivalent way of constructing signatures on arbitrary messages

Selective Forgery- C forges a signature for a particular message

Existential Forgery- C forges a signature for at least one message.

Requirements of Digital Signature: Signature must be a bit pattern that depends

on the message being signed Signature must use some info unique to the

sender to prevent both forgery and denial Must be relatively easy to produce the

signature Must be relatively easy to recognize and

verify signature

Must be computationally infeasible to forge the signature

Must be practical to retain a copy of signature in storage

A secure hash function provides the basis for satisfying these requirements

Confidentiality in Direct Digital Signatures Scheme is provided by encrypting the message plus signature with a shared secret key (symmetric encryption). Only Sender and Receiver involved. Receiver knows public key of Sender.

Many Signature Schemes exist:

Elgamal Scheme

Schnorr

Digital Signature Standard

Due to time limitations, details are not discussed here.

SSL/TLS (Transport Layer Security) RFC 5246 Evolved through

o Unreleased v1 (Netscape)o Flawed-but-useful v2o Version 3 from scratcho Standard TLS1.0

• SSL3.0 with minor tweaks, hence Version field is 3.1 Defined in RFC2246, http://www.ietf.org/rfc/rfc2246.txt

Open-source implementation at http://www.openssl.org/

Overview Establish a session

o Agree on algorithmso Share secret keyo Perform authentication

Transfer application datao Ensure privacy and integrity

Setting up secure channel in the Web Application-independent security protocol that is

logically layered on top of a transport protocol. Implemented above TCP

Implementation choices SSL/TLS provided as part of underlying protocol suite and

therefore transparent to applications Embedded in specific packages such as Browsers

Architecture

Record Protocol to transfer application and TLS information

A session is established using a Handshake Protocol

TLS Record Protocol

Handshake Protocol

Alert Protocol

ChangeCipher Spec

Three pieces of informationo Content type

• Application data• Alert• Handshake• Change_cipher_spec

o Content length• Suggests when to start processing

o SSL version• Redundant check for version agreement

Max. record length 214 – 1 bytes MAC

o Datao Headerso Sequence number

• To prevent replay and reordering attack

Negotiate Cipher-Suite Algorithms-list that contains cryptographic algorithms supported by client

Establish and share secret key

Optionally authenticate server and/or client. Server passes certificate containing its public key to client signed by CA. Client may reciprocate. Client generates a random number that is used by both sides to construct session key (for duration of session).

• Hello messages

• Certificate and Key Exchange messages

• Change CipherSpec (contains mainly Cipher Algorithm, MAC Algorithm, CipherType-Stream or Block etc) and Finished messages

Conveys SSL-related alerts to peer entity. Alert messages are compressed and

encrypted Alert the other side of exceptions

o Different levels: “Warning”, “Fatal” etco Terminate and session cannot be resumed: If Alert is

“Fatal”

Closure notify: end of communicationo To prevent truncation attack (sending a TCP FIN before

the sender is finished)

TLS is susceptible to a number of denial-of-service (DoS) attacks. In particular, an attacker who initiates a large number of TCP connections can cause a server to consume large amounts of CPU for doing RSA decryption.

However, because TLS is generally used over TCP, it is difficult for the attacker to hide his point of origin if proper TCP SYN randomization is used by the TCP stack.

Because TLS runs over TCP, it is also susceptible to a number of DoS attacks on individual connections. In particular, attackers can terminate connections, or forge partial TLS records, thereby causing the connection to stall.

These attacks cannot in general be defended against by a TCP-using protocol. Implementers or users who are concerned with this class of attack should use IPsec AH or ESP .

1. www.ietf.org2. RFC28223. RFC52464. RFC25105. RFC15096. RFC 44627. RFC 33948. X.509v3

Daemen Joan, V. R. (2002). The Design of Rijndael AES. Springer.

Peikari Cyrus, C. A. (2004). Security Warrior. Oreilly. Stallings, W. (2010). Cryptography and Network

Security: Principles and Practice. Pearson(5th Ed). Suku, N. (n.d.). Network Systems Security.

Retrieved Nov 2010, from Lyle SMU: http://lyle.smu.edu/~nair/courses/7349/index.html

Tanenbaum, A. S. (2007). Distributed Systems: Principles and Paradigms. Pearson(2nd Ed).