authentication key distributionkeldefra/teaching/fall2016/uci... · 2016-10-27 · key distribution...

Lecture 9

1

Authentication&

KeyDistribution

Wherearewenow?

• We“know”abitofthefollowing:• Conventional(symmetric)cryptography• HashfunctionsandMACs• Publickey(asymmetric)cryptography• Encryption• Signatures• Identification(Fiat-Shamir)+ZeroKnowledge

• Andnowwhat?• Protocols(more“complicated”beasts)• Authentication/Identification• KeyDistribution

2

SecureProtocols

• A protocol isasetofrulesforexchangingmessages between2ormoreentities/parties

• Aprotocolhasanumberofrounds (>1)andanumberofmessages (>1)

3

1.HelloBob!

2.Goodday,Alice!

3.Howareyou?

SecureProtocols• Amessage isaunitofinformation/datasentfrom

oneentity/partytoanotheraspartofaprotocol

• Around isabasicunitofprotocoltime:1. Wakeupbecauseof:

a) Alarmclockb) Initialstartorc) Receivemessage(s)fromother(s)

2. Computesomething3. Sendmessage(s)toothers4. Repeatsteps2-3,ifneeded5. Waitformessage(s)orsleepuntilalarmclock

4

What’saSecureProtocol?

• Whenactinghonestly,entities/parties(participants)achievethestatedgoal oftheprotocol,e.g.,:• AsuccessfullyauthenticatestoB,orBtoA• AandBmutuallyauthenticateeachother• AandBexchangeafreshsessionkey

• Adversarycandefeatthisgoal• e.g.,bysuccessfullyimpersonatingAinanauthenticationprotocolwithB

5

TheEntities(2-PartySetting)

• Alice andBob•wanttomutuallyauthenticateand/orshareakey

• Eve,theadversary•passiveoractive

• MorecomplexprotocolsmayinvolveaTrustedThirdParty(TTP)•3rd partytrustedbybothAliceandBob

6

• Entity Authentication:• corroborationthatanentityistheoneclaimed

• Unilateral Authentication:• entityauthentication:providingoneentitywithassuranceoftheother’sidentity,butnotviceversa

•MutualAuthentication:• entityauthenticationwhichprovidesbothentitieswithassuranceofeachother’sidentity

7

Definitions

8

Examples:• Banktransactions,e.g.,cashwithdrawals• Remotelogin• Fileaccess• P2Ptransaction Hasuser’s

secrets

Doesn’t

Sendsecretorproveknowingit?

TTP

PeerOrServer

Purpose

BasisforAuthentication

• Somethingyouknow (aPIN,orpassword)• Somethingyouhave:• Asecuretoken,e.g.,thatgeneratesaone-timepassword• Keyembeddedina“securearea” onacomputer,inbrowsersoftware,etc.• Asmartcard(whichmaycontainkeysandcanperformcryptographicoperationsonbehalfofauser).

• Somethingyouare(abiometric)

9

10

• PIN-,PW-,Biometric-basedschemes

• Kerberos

• SecureID tokens

• Iris/retinascanners

• Thumbprint&hand/palmprint

• Handwritingacceleration&pressure

• PublicKeyIdentificationSchemes:

• Fiat-Shamir,etc.

• Authenticationprotocols

• Conventional- andpublickey-based(coveredlater)

ConcreteScenarios

11

• Humansarenotoriouslyunreliable• Humanmemoryisveryvolatilestorage

• Whatahumancanremember:• PIN(nomorethan6-8digits)• Password(awordorashortphrase)

• Canahumandosingle-digitsums?Forgetit…

HumanFailings

Biometrics

• Accuracy:• FalseAcceptanceRate(FalsePositive)• FalseRejectionRate(FalseNegative)

• Retinalscanner,fingerprintreader,handprintreader,voiceprint,keystroketiming,signature(shapeorpressure),etc.

12

Fingerprints

• Vulnerability:• Dummyfingersanddeadfingers• Lostfingers

• Suitabilityandstability:• Notforpeoplewithhighprobabilityofdamagedfingerprints(e.g.,exema)• Notfor kids whoarestillgrowing• Othernoisesources:thermalandopticalnoise,temperatureaffectingskincondition…

13

VoiceRecognition

• Singlephrase:• Canusetaperecordertofake

• Stability:• Backgroundnoise• Colds,vocalcorddamage/strain,laughinggasJ• Usewithpublicphones

14

KeystrokeTiming

• Eachpersonhasadistincttypingtimingandstyle•Hand/fingermovements

• Suitability:•Bestdonefor“local”authentication• Avoidnetworktrafficdelay

15

(Non-digital)Signatures

• Machinescannot(yet)matchhumanexpertsinrecognizingshapesofsignatures

• Addinformationonaccelerationand/orpressure• Signingonaspecialelectronictablet

16

SecureID/SecureToken

17

89458920 display

power

Id-basedkey(inside)

895980390409982

Serial#

TTP/Server:secure&knowsallsecrets!

SecureID/SecureToken

18

TTP/Server:secure&knowsallsecrets!

Authentication(Protocols)

19

Protocolap1.0: Alicesays“IamAlice”

inanopennetwork,Bobcannot“see”Alice,so

EvesimplydeclaresherselftobeAlice

Authentication:AnotherTry

20

Protocolap2.0: Alicesays“IamAlice”inanIPpacketcontaininghersourceIPaddress

Evecancreateapacket“spoofing”

Alice’saddress

21

Protocolap3.0: Alicesays“IamAlice”andsendshersecretpasswordto“prove”it.

playbackattack: EverecordsAlice’spacket

andlaterplaysitbacktoBob

“I’mAlice”Alice’sIPaddr

Alice’spassword

OKAlice’sIPaddr


Alice’spassword


22

Protocolap3.1: Alicesays“IamAlice”andsendsherencrypted secretpasswordto“prove”it.

recordand

playbackstillworks!


encryptedpassword

OKAlice’sIPaddr


encryptedpassword


23

Goal: avoidplaybackattack

Nonce: numberusedonce(R)ap4.0: toproveAlice“live”,BobsendsAlicenonce,R.Alice

mustreturnR,encryptedwithsharedsecretkey

“IamAlice”

R

E(K,R) Aliceislive,andonlyAliceknowskeytoencryptnonce,soit

mustbeAlice!• KmaybederivedfromAlice’spassword…• ThisprotocolworksifBobneverauthenticatestoAliceusingK

Authentication:YetAnotherTry

Authentication:ap5.0

ap4.0requiressharedsymmetrickey• canweauthenticateusingpublickey?ap5.0: noncesandpublickeycryptography

msg2=R

UsingPKA,BobverifiesAlice’ssignatureofRinmsg3.SinceRisfreshandonlyAlicecancomputesignaturesusingSKA,BobconcludesthatAliceisreallythere.

msg3=SIGN(SKA,R)

TheProtocol(Nonces)

1. Aà B: ”HiBob,it’s,me,Alice”

2. Bà A: R (challenge)

3. Aà B: E(K,R||B) (response)

25

WhynotsimplysendE(K,R)inlastmessage?

TheProtocol(whatif?)

1.Bà A(Eve):“HiAlice,it’smeBob”

1.Eveà B: ”HiBob,it’s,me,Alice“

2.Bà A(Eve):R (challenge)

2.Eveà B:R

3.Bà Eve:E(K,R)

3.Eveà B:E(K,R) (response)26


2. Bà A: R

3. Aà B: E(Kab,R)orE(K,R||B)

27

• KabisonlyusedinAàBdirectionandadifferentkey(Kba)isusedinBàAdirection• Alternatively,canusethesameKinbothdirectionsbutincludeexplicitdirection

identifierinmsg

TheProtocol(Nonces)


2. Bà A: Sb (challenge)incrementSb

3. Aà B: E(K,Sb||B) (response)

■ NoPRNGneeded■ BothAandBmustrememberSb

28

TheProtocol(Seq.#s)

Time-Stamps

Inclusionofdate/time-stampinmessageallowsrecipienttocheckforfreshness(aslongastime-stampisprotectedbycryptographicmeans).

1.Aà B:E(K,TIMEA ||B)

resultsinfewermessagesinprotocol

Butrequiressynchronizedclocks…(SimilartotheSecureIDscenario)

29

KeyDistributionandManagement

• Conventional(Secret)keydistribution

• Publickeydistribution

30

TrustedIntermediaries

SymmetricKeyProblem:•Howdotwoentitiesestablishsharedsecretkeyoveradistance(i.e.,overanetwork)?

Solution:•Mutuallytrustedon-linekeydistributioncenter(KDC)actsasintermediarybetweenentities

PublicKeyProblem:•WhenAlicegetsBob’spublickey(fromawebsite,email,disk,bboard),howdoessheknowitisreallyBob’s?

Solution:•Trustedoff-line certificationauthority(CA)

31

KeyDistributionCenter(KDC)

• Responsiblefordistributingkeystopairsofusers(hosts,processes,applications)

• EachusermustshareauniquemasterkeywiththeKDC• UsethiskeytocommunicatewithKDCtogetatemporarysession keyforestablishingasecure“session”withanotheruser/program/host/entity• Eachmasterkeyisdistributed(agreedupon)insomeoff-linefashion(inperson,bysnail-mail,etc.)

32

KeyDistributionCenter(KDC)• AliceandBobneedtoshareakey• KDCsharesdifferentmasterkeywitheachregistereduser(manyusers)• AliceandBobknowtheirownmasterkeys:

KA andKBforcommunicatingwithKDC

33

KB KX

KY

KZ

KPKB

KA

KAKE

KDC

authentication key distributionkeldefra/teaching/fall2016/uci... · 2016-10-27 · key distribution...

Documents