ECS726: Security and Authentication
Week 5: Cryptographic Protocols, Key Management
Digital Certificates
EECS, QMUL
Copyright By PowCoder代写 加微信 powcoder
Table of contents
1. Cryptographic Protocols
Analysing a simple protocol
Authentication and Key Establishment (AKE) protocols
2. Key Management
3. Public key certificates
Cryptographic Protocols
protocols?
We follow protocols in real life: for example when we are introduced to a new person, we smile, shake hands (pre-covid protocol), we exchange few words etc
individuals follow protocols for weddings, funerals, graduations etc etc, the state establish diplomatic protocols, and several protocols are in place for all sorts of eventuality (chemical/nuclear incidents, pandemics, etc…)
What is a cryptographic protocol?
A protocol is similar to an algorithm in that it is a precise description of a procedure and regulations in a given environment defined by a set of assumption to achieve a specific goal. Differently than an algorithm, a protocol involves multiple-parties. A protocol typically involves exchange of specifically formatted messages in a specific sequence order between two or more parties to achieve a clear goal.
A cryptographic protocol in particular is a specification of how to apply cryptographic primitives and in what precise sequence of message-passing and actions between entities so that a specific set of security goals are met.
Components of a cryptographic protocol
A cryptographic protocol needs to specify its:
◃ protocol assumptions – any cryptographic prerequisites concerning the environment in which the protocol will be run, e.g. possession of cryptographic keys by the participating entities;
◃ protocol flow – the sequence of communications (steps or passes) which need to take place between the entities involved in the protocol;
◃ protocol messages – the content of each message exchanged between entities;
◃ protocol actions – the details of any actions (operations) an entity needs to perform after
receiving, or before sending, a protocol message. 4
Components of a cryptographic protocol
Components of a cryptographic protocol
◃ protocol assumptions – What needs to have
happened before the protocol is run?
◃ protocol flow – Who sends a message to whom, and in what order?
◃ protocol messages – What information is exchanged at each step?
◃ protocol actions – What needs to be done between steps?
Cryptographic protocol standards
◃ Designing secure cryptographic protocol that meet their specified goals can be surprisingly difficult (as we will see through an example later).
◃ So as much as possible, we should use the cryptographic protocols in standards. For instance:
– The PKCS standards for public-key cryptography.
– ISO/IEC 11770 for mutual entity authentication and
key establishment.
– SSL/TLS for setting up a secure communication
channel (as we see next week).
Analysing a simple protocol
In this scenario, we suppose Alice and Bob have access to a common network. Periodically, at any time of his choosing, Bob wants to check Alice is still alive and connected to the network. This is our main security objective, which we will refer to as a check of liveness
we assume Alice and Bob are two entities in a network consisting of many such entities, all of whom regularly check the liveness of one another, perhaps every few seconds. We thus set a secondary security objective that whenever Bob receives any confirmation of liveness from Alice, he should be able to determine precisely which liveness query she is responding to.
Analysing a simple protocol: Notations
typical notations in crypto
Example Protocol 1
Example Protocol 1: Analysis
◃ Protocol 1 analysis
• Data origin authentication of Alice’s reply : MAC
• Freshness of Alice’s reply : nonce
• Assurance Alice’s reply corresponds to Bob’s request
1 rB , nonce Bob generated for this run. 2 reply contains the identifier Bob.
• Protocol Assumptions
1 Bob has access to a source of randomness.
2 Alice and Bob already share a symmetric key K. 3 Alice and Bob agree on the use of a strong MAC algorithm.
Protocol 1 meets the security goals and hence is a suitable protocol to use in our simple application. 10
Example Protocol 2
Example Protocol 2: Analysis
◃ The analysis of Protocol 2 is the same as for Protocol 1, except for: Data origin authentication of Alice’s reply: Digital signature
Protocol Assumptions
• Bob has access to a source of randomness. As for Protocol 1.
• Alice has been issued with a signature key, and Bob has access to a verification key corresponding to Alice’s signature key. This is the digital signature scheme equivalent of the second assumption for Protocol 1.
• Alice and Bob agree on the use of a strong digital signature scheme.
Protocol 2 also meets the three security goals.
Protocols 1 and 2
which is better? Protocol 1 or Protocol 2?
Example Protocol 3
Example Protocol 3: reflection attack
(reflection attack): to prevent it include identifiers of recipients in protocol messages
Example Protocol 4
Protocol 4 analysis
◃ Protocol Assumptions: identical to Protocol 1, except that we assume Alice and Bob have agreed on the use of a strong symmetric encryption algorithm E (rather than a MAC). Issues:
• Encryption does not, in general, provide data origin authentication.
• Encryption tends only to be used in this way if confidentiality of the message data is also required.
Example Protocol 5
Protocol 5 analysis
◃ Assumptions: same as protocol 1, except for the source of randomness being replace by Bob can generate and verify integrity protected timestamps.
• Data origin authentication of Alice’s reply. As for Protocol 1.
• Freshness of Alice’s reply. The reply text includes the timestamp TB which Bob generated at the start of the protocol.
• Assurance that Alice’s reply corresponds to Bob’s request: timestamp, identifier Bob.
Hence Protocol 5 meets the three security goals.
Protocol 5 analysis
◃ timestamp TB needs to be integrity-protected, or:
• At 15.00, the attacker sends Alice a liveness check
withTB =17:00
• Alice replies to Bob with TB = 17 : 00
• The attacker intercepts and blocks the reply from
reaching Bob, then stores it.
• The attacker kills Alice.
• At 17.00, Bob sends a genuine request to Alice.
• The attacker intercepts the request and sends back
the previously intercepted reply from Alice.
• Bob accepts the reply and assumes that Alice is OK
Example Protocol 6
Example Protocol 6
Is protocol 6 correct?
Example Protocol 7
Example Protocol 7
Is protocol 7 correct?
Analysing a simple protocol: Summary
There is no one correct way to design a cryptographic
protocol .
• The choice of the most suitable protocol design thus
depends on what assumptions are most suitable for a
given application environment.
• The deficiencies of several of these protocol variants
are very subtle. Given that this application is artificially simple, the complexity of designing protocols for more intricate applications should be clear.
• Designing cryptographic protocols is hard !!
◃ Authentication and Key Establishment (AKE) protocol Objectives:
• Mutual entity authentication
• Establishment of a common symmetric key AKE protocol goals:
• Mutual entity authentication.
• Mutual data origin authentication. • Mutual key establishment.
• Key confidentiality.
• Key freshness
• Mutual key confirmation.
• Unbiased key control.
Diffie-Hellman
◃ Diffie-Hellman key agreement protocol
• The basis for majority of modern AKE protocols
based on key agreement
• Designed for environments where secure channels
do not yet exist
• Based on the difficulty of discrete logarithm.
Diffie-Hellman
◃ Diffie-Hellman key agreement protocol
Diffie-Hellman
◃ Diffie-Hellman key agreement protocol (picture)
Diffie-Hellman key agreement protocol
◃ The idea of the protocol is simple:
• Alice and Bob agree on a large prime p and an integer q < p 1
• Alice choose a secret random n, Bob chooses a secret random m
• AlicesendtoBobN =qn modp,Bobsendto = qm mod p
• Alice computes A = Mn = qmn mod p, Bob computes B=Nm =qnm modp
• notice A = B (because xyz = xy∗z = xzy) hence Alice and Bob share key A
1q generator of Z/pZ, cyclic group with p elements
Diffie-Hellman toy example
• Alice and Bob agree on the prime p = 23 and integer q=5
• Alice choose the secret integer 4, Bob chooses the secret integer 3
• Alice send to Bob 4 = 54 mod 23, Bob send to Alice 10=53 mod23
• AlicecomputesA=18=104 =534 mod23,Bob computesB=18=43 =543 mod23
• notice A = B (because 543 = 512 = 534) hence Alice and Bob share key 18
Diffie-Hellman toy example: security
the attacker knows p = 23, q = 5, M = 4, N = 10
• healsoknowsthatM =5x mod23forsomex and
N =10=5y mod23forsomey
• to get the shared key A(= B) he would need to derive
• if he derives x he can then he can compute
A=10x mod23
• if he derives y he can then he can compute
B=4y mod23
• to derive x or y is hard when p,q,M,N are large integers!
Diffie-Hellman key agreement protocol
◃ Diffie-Hellman key agreement protocol. For an attacker to recover the secret key he should solve discrete logarithm, which is hard!
• the attacker knows p,q,M = qm mod p,N = qn mod p butheneedsB=Nm =qnm modp
• for this he would need to compute n from
N=qn modp(orcomputemfromM=qm modp)
• to compute n (or m) is to solve the discrete logarithm problem.
Diffie-Hellman: the man in the middle attack
◃ An attacker Fred could however impersonates Bob to Alice and Alice to Bob,
Fred follows Diffie-Hellman and generates two keys: one to talk to Alice, one to talk to Bob.
once this is done Alice thinks she is talking to Bob but she is talking to Fred and the similarly for Bob.
Diffie-Hellman: man in the middle
Diffie-Hellman: man in the middle
◃ • Alice and Fred end up sharing the key ga∗f
• Alice thinks she is sharing the key ga∗f with Bob • Bob an Fred end up sharing the key gb∗f
• Bob thinks he is sharing the key gb∗f with Alice • Fred can now listen, delete and manipulate the
conversation between Alice and Bob
Diffie-Hellman: mitigating man in the middle
◃ How to make Diffie-Hellman works then? use public key certificates, (also known as a digital certificate) A public key certificate, includes
• the public key,
• information about the identity of its owner (called the
• the digital signature of an entity that has verified the
certificate’s contents (called the issuer).
((n,e), "Alice public key", Signed by Amazon, ...)
the issuer is an authority trusted by all parties
Diffie-Hellman: station to station
◃ variation of Diffie-Hellman to avoid man in the middle: public parameters q < p (as for D-H)
• Alice sends Bob qmmod p and her certificate CA
• Bob verifies CA and if ok sends Alice
qnmod p||CB||SigB(Alice||qnmod p||qmmod p)
• Alice sends A(Bob||qmmod p||qnmod p)
• now they both can compute a shared key K = qmn
• they have mutual authentication: Bob knows he is
talking to Alice, Alice know she is talking to Bob.
using public key certificates
◃ now when Alice wants to communicate with Bob to do Diffie- KE (or for any other identification protocol really) Alice can use public key certificates
• Question: do you still need Diffie-Hellman to create symmetric keys if you use public key certificates (which already include keys?)
• you could do without but then all communications would rely on the public key, by doing a Diffie- KE, even if someone steal the private key of the public key scheme, he still couldn’t decrypt the messages encrypted with the Diffie-Hellman keys, hence one has an additional layer of security.
Key Management
Key Management
◃ • Crucial to the security of any cryptosystem. • Key management: secure administration of
cryptographic keys.
• Key lifecycle:
• Key generation : the creation of keys.
• Key establishment : the process of making sure keys
reach the end points where they will be used. the
most difficult phase of the key lifecycle to implement. • Key storage : the safekeeping of keys.
• Key usage : how keys are used.
Key length
• Key length recommendations for symmetric cryptography tend to be algorithm independent
• Key length recommendations for public key cryptography tend to be algorithm specific for symmetric keys for example: a 10 years
protections is estimated to require 112 bits, 20 years 128 bits. 256 bits is estimated to be good for long term protection including quantum computers.
Key hierarchy
◃ Not all keys are created equal: e.g. some keys are used to create other shorter terms keys, also a key guarding a keychain is more valuable than any other key in the chain... Typically:
• top of the hierarchy are the master keys
• then keys encrypting keys
• then data keys (e.g. generated each time you login at
Key hierarchy
◃ Not all keys are created equal: e.g. some keys are used to create other shorter terms keys, also a key guarding a keychain is more valuable than any other key in the chain... Typically:
• top of the hierarchy are the master keys
• then keys encrypting keys
• then data keys (e.g. generated each time you login at
Keys: A key distribution scenario
Consider a simple two level hierarchy consisting of
only master and data keys.
• If we have a network of n users, then the number of
possible pairs of users is n(n − 1)/2, which is the number of shared master keys. This is not practical for a network with many users.
• Use a Key Centre (Key Distribution Centre) instead, a trusted third party.
• Each user in the network shares a master key with the KC.
Keys: A key distribution scenario
◃ So whenever Alice wants to talk to Bob she uses the Key Distribution Centre to establish a trusted connection
• Alice ⇒ Key Distribution Centre ⇒ Bob.
• The Key Distribution Centre establishes a shared key
Alice and Bob can use to communicate
• the communication between Alice and Bob can then
either go at each step via the Key Distribution Centre (translation) or is only between Alice and Bob once key is established (generation).
Key distribution using public key encryption
◃ we already touched this fundamental question: How can we be sure of the identity of someone? We said: Solution: public key certificate.
let’s see more details:
Public key certificates
Public key certificates
A public key certificate is data binding a public key to data relating to the assurance of purpose of this public key. It can be thought of as a trusted directory entry in a sort of distributed database.
A public key certificate:
• provides a ‘strong association’ between a public key and the owner of that key (the entity whose identity is linked to the public key);
• provides a ‘strong association’ between a public key and any other relevant data (such as expiry dates and usage restrictions).
Public key certificate
Contents of a Public Key Certificate:
• Name of owner . The name of the owner of the public key. This owner could be a person, a device, or even a role within an organisation.
• Public key value . The public key itself.
• Validity time period . This identifies the date and time
from which the public key is valid and, more
importantly, the date and time of its expiry.
• Signature . The creator of the public key certificate digitally signs all the data that forms the public key
certificate, including the name of owner, public key
value, and validity time period.
• And more? ( X.509: public key certificate standard) 48
Certificate authority
public key certificate are issued by a Certificate authority (CA). The CA role: is
• Certificate creation : creating and signing the public key certificate, and then issuing it to the owner.
• Certificate revocation . The CA is responsible for revoking the certificate in the event that it becomes invalid.
• Certificate trust anchor . The CA acts as the point of trust for any party relying on the correctness of the information contained in the public key certificate.
chain of trust
A certificate chain is a list of one or more CA certificates (usually the last one being a self-signed certificate), with the following properties:
• The Issuer of each certificate (except the last one) matches the Subject of the next certificate in the list
• Each certificate (except the last one) is signed by the secret key corresponding to the next certificate in the chain (i.e. the signature of one certificate can be verified using the public key contained in the following certificate)
• The last certificate in the list is a trust anchor: a certificate that you trust because it was delivered to
you by some trustworthy procedure 50
certificates: example
You can check certificates for a website by clicking on the lock symbol next to https. For qmplus.qmul.ac.uk you will see:
• CA list is: Amazon, Amazon Root CA 1
• qmplus is signed by Amazon with SHA-256 with RSA Encryption (you can see the RSA public key in the certificate)
• you can see information for the other elements in the chain
self-signed certificates
“anyone” can in principle create a certificate not signed by a CA, this is a self-signed certificate
A self-signed certificate
• doesn’t provide any trust value
• for example if a website uses a self-signed certificate (e.g. to provide HTTPS services), visitors to that website may not be connected to their intended destination...
certificates
To get a “proper” certificate one should
• register with a registration authority RA who will do due diligence, e.g. the company exists etc...
• then (pay to) get a certificate from a recognised CA
• RA and CA may be the same company (but they are different roles)
Questions?
Next week: Example Applications of Cryptography.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com