psc cybersecurity 2 crypto v1

Cri$cal Infrastructure Security: The Emerging Smart Grid

Cyber Security Lecture 2: Cryptographic Basics

Carl Hauser & Adam Hahn

Overview

Crypto principles Historical ciphers Modern symmetric ciphers Modern asymmetric ciphers Cryptographic Hash Func$ons Authen$ca$on

Message authen$ca$on code Digital signature

Cryptosystem Overview

Elements of a Cryptosystem

Threats to cryptosystems Threats (theore$c)

Brute-force aLack try every possible key un$l you can nd intelligible transla,on

Cryptanalysis leverage knowledge about crypto algorithms, and/or some knowledge about the ciphertext and plaintext

Threats (real-world) System implementa$on it is dicult to correctly design, implement, and

deploy cryptosystems. Rubber-hose cryptography human factors/coercion

ALacker capabili$es: Cipher only aLacker only knows cipher text Known plaintext aLacker knows plain and ciphertext Chosen plaintext aLacker can pick cipher text to encrypt (important in public

key crypto) Chosen ciphertext - aLacker can choose ciphertext to be decrypted by system

Cryptosystem Principles

Kerckho's principle (more specic deni$on) made assump$on that aLacker knows how the cryptosystem algorithms work, only the key must be protected

Perfect secrecy Cipher text conveys no informa$on about plain text

Cant do cryptanalysis or brute force aLacks

Overview



Subs$tu$on Ciphers

Transposi$on Ciphers

One Time Pad

Keys are never re-used (one-$me) Achieving this is hard: rst to generate such key material and second to share it with your correspondent(s)

One-$me Pad (cont.) Example

Z K J W Z Y F U P S X W P E

W W W I G Y M B P Q N Y L L D O N O T A T T A C K Y E T

Op#on 2 Key 2: Plaintext 2:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Key Elements: K:

Z R Q W X O M G D E G F B I

Message(P): Random Key (k):

A T T A C K T O M O R R O W

Algorithm: Ci= (Pi + ki) mod 26

Cipher Text(C):

ALackers dilemma: Mul$ples keys can be found the

decrypt to many dierent credible plaintexts!!!

Z R Q W X O M G D E G F B I

A T T A C K T O M O R R O W

Op#on 1 Key 1: Plaintext 1:

???

Overview



Modern Symmetric Encryp$on Symmetric same key used for enciphering and deciphering

Combine mul$ple rounds of Subs$tu$on and Transposi$on

Approaches: Block cipher Stream cipher

Block Ciphers Breaks plaintext into n-bit blocks, and then encrypts each

block individually

Elements Key - random string of bytes, (56 < # of bits < 256 bits) Encryp$on algorithm - Con$nued rounds of:

Subs$tu$ons Transposi$ons

Decryp$on algorithm inverse process of encryp$on

Cipher Text n-bits

Plain Text

K K K K K K K K

n-bits

DES / 3DES / AES

DES Data Encryp$on Standard Approved by NBS (NIST) in 1977 Based on Horst Feistels Lucifer

cipher 56 bit keys (8 bits for parity) S-box (subs$tu$on box) developed

by NSA Key size too small for modern use

3DES Implemented to extend life of DES Uses three keys (k1,k2,k3) to

provide more security Not meant to be long term

solu$on!

Advanced Encryp$on Standard (AES) Won NIST sponsored

compe$$on for DES replacement in 2001, called AES

Really called Rijndael cipher, developed by Joan Daemen and Vincent Rijmen

Benets Performance, security

Improved key sizes 128, 192, 256 bits

How secure is DES/AES? Larger key length

56 bit key = 256 (7.2 x 1016) possible keys 128 bit key = 2128 (3.4 x 1038) possible keys 256 bit key = 2256 (1.2 x 1077) possible keys

How big is 2128??? 340,282,366,920,938,463,463,374,607,431,768,211,456

Or three hundred forty undecillion, two hundred eighty-two decillion,

three hundred sixty-six nonillion, nine hundred twenty oc$llion, nine hundred thirty-eight sep$llion, four hundred sixty-three sex$llion, four hundred sixty-three quin$llion, three hundred seventy-four quadrillion, six hundred seven trillion, four hundred thirty-one billion, seven hundred sixty-eight million, two hundred eleven thousand, four hundred ty-six

Source: hLp://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/

Brute force decryp$on $me Currently 33,862,700 GFlops/s or 3.4 x 1016

Assume 1000 opera$ons per decryp$on Decryp$ons /second: 3.4 x 1013 Seconds in year: 3.15 x 107 Decryp$ons/year: ~1.1 x 1021

3.13 x 1013 microseconds/year

Decryp$on $mes: DES (56 bit) = 256/(3.4x1013) = ~35 minutes AES (128 bit) = 2128/(1.1x1021) = 3.1 x 1017 years AES (256 bit) = 2256/(1.1x1021) = 1.1 x 1056 years

Block Chaining

Plain text 128bit AES-ECB 128bit AES-CBC

How do we handle messages longer than the block size Example

Electronic Code Book (ECB) each block encrypted independently from previous

Similar blocks encrypt to same output Cipher Block Chaining (CBC) each block XORs the output of the

previous block Similar blocks encrypt to dierent output

Problems with Symmetric Encryp$on

Overview



Fundamental Idea Encryp$on and Decryp$on use dierent keys

Also called public key crypto Invented in mid 1970s A completely dierent viewpoint on messages

Instead of consis$ng of symbols that could be subs$tuted or rearranged, look at messages as numbers that can added, subtracted, mul$plied, divided, exponen$ated, etc.

Based on one-way func$ons Discrete logarithm Integer factoring Ellip$c curve arithme$c

RSA Cryptosystem

RSA Keys

(5,35) is a public key; anyone, including Trudy can encrypt with it; (29,35) is Bobs private key only he is able to decrypt messages created with the public key

Asymmetric Encryp$on Challenges Asymmetric cryptosystems are many $mes more

computa$onally expensive than good symmetric systems

Solu$on Use an asymmetric system to agree on a symmetric key Encrypt large amounts of data using the symmetric key

Source: S. Fuloria, R. Anderson, K. McGrath, K. Hansen. F, Alvarez. The Protec$on of Substa$on Communica$ons. SCADA Security Scien$c Symposium. 2010

Overview



Cryptographic Hash Func$on Hash func$on: one way func$on mapping a variable length string to

xed length digest Common func$ons: SHA(1,2,3), MD5 Used for:

Digital Signatures HMACs Password storage

Three key requirements: Preimage resistant Second preimage resistant Collision Resistant

Hash func$ons examples Unix commands

# echo "This is a test message to demonstrate hash func$ons" | sha1sum > 799772e0410af26e43ee279af9f630150c7bb8bb

# echo "This is a test message to demonstrate hash func$ons." | sha1sum

> 5bd891f72d006b2ea8b0ad36457fe7cce6f21c

# echo "This is a tset message to demonstrate hash func$ons" | sha1sum > d3e266656a24a986e6303eccab4474447b887def

# echo "This is a test message to demonstrate hash func$ons" | sha512sum

>72a26cb6e857cecbaf6b2b88bfaebd680de0551e091e87e7f822c10 933ce58c696356d88124a1141eec089a3a2e8f2cecb0916c567f8 20c12d07c598d790c5

Overview



Hash Message Authen$ca$on Code (HMAC)

MAC cryptographic digest appended to a communica$on Cannot be manipulated by aLack without the key used to create it

HMAC - MAC based on hash func$ons Stronger security proper$es

Usually faster than tradi$onal symmetric crypto algs (e.g., DES) Less vulnerable to collisions than just hash func$ons

Used with modern hashes (MD5, SHA, etc)

HMAC output is appended to message Receiver veries message by compu$ng the HMAC and compare with the

appended HMAC

HMAC basic example: HMAC(k, m) = H(K | m)

Length extension aLack BeLer example

HMAC(k, m) = H(K | H(K | m))

HMAC usage Plaintext Key (k)

Bob

Alice

HMAC

HMAC Func$on

Plaintext

Key (k) HMAC

HMAC Func$on

Plaintext

HMAC Plaintext

HMAC

???

Yes = OK No = modied/spoofed

Network

Overview



Digital Signatures

U$lize public key crypto in reverse, to provide authen$city Sender encrypts (signs) with private key (usually a message hash)

Receive decrypts (veries) with public key Upon successful decryp$on (verify), recipient knows message came from someone holding the corresponding private key

Anyone can verify (because verifying uses the public key)

Digital Signatures Plaintext Key (PRa)

Hash Hash

Plaintext

Plaintext

???

Network

Alice Sign

DS

DS

Plaintext Key (PUa)

Hash Hash

Verify

DS

Bob

Alices private key Alices public key

Key (PRa)

Key (PUa)

Hash

Authen$ca$ng Principals

Trusted third par$es

Some en$ty to aLest to the rela$onship between the cryptographic keys and the real-world principals to which they belong

Examples: Key server (symmetric keys) Cer$cate authority (asymmetric keys)

About trust: trust is reliance on another to perform as expected. To say something is trusted is not a statement about its reliability but rather a statement about risk!

Needham-Schroeder Protocol using Symmetric Keys

The Key Server is the trusted third party.

PKI: Public Key Infrastructure

A system of protocols and third par$es to make public-key encryp$on systems useful in prac$ce

Cer$cates Help develop root of trust for issuing public keys Based on trusted cer$cate authori$es (CA)

E.g., Verisign, Comodo, GoDaddy Challenges include key issuing and revoca$on

What are the trust assump#on being made here?

Cer$cate Crea$on

Cer$cate Usage

1. Alice request communica$on with Bob

2. Bob sends signed cer$cate to Alice

3. Alice (already has CA public key) creates hash of cer$cate, checks to see if the hash matches the CA signed part of cer$cate

4. If equal, cert has not been tampered with and public key in cer$cate can be trusted

5. If not equal, poten$ally spoofed/tampered communica$on!

Cer$cate Example

Cer$ca$on Hierarchies

Crypto Warnings

Strong crypto != strong security Crypto usually bypassed not broken

Source: hLps://www.schneier.com/paper-design-vulnerabili$es.pdf, hLp://xkcd.com/538/

Vulnerabili$es in Design Implementa$on Installa$on

Avoid rolling your own crypto!!!

I havent told you enough to implement ANY of this securely There are MANY PITFALLS in the prac$cali$es

My best recommenda$on Use well-researched, standard techniques Use library implementa$ons and pay aLen$on to details about how to use them correctly

Inves$gate the literature for recent status of both the library and underlying technique

Consult an ac$ve expert

psc cybersecurity 2 crypto v1

Documents