[soen321-f04] material for week 6.1 (Oct 18)[soen321-f04] material for week 6.1 
(Oct 18)
David K. Probst PROBST at vax2.concordia.ca 
Mon Oct 18 13:59:05 EDT 2004 
  Previous message: [soen321-f04] week 7 material (Oct 14) 
  Next message: [soen321-f04] week 8 lecture material (Oct 26) 
  Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 



simple cryptographic examples
_____________________________

Integrity verification, verification of a digital signature, and indeed, most
forms of cryptographic challenge-response authentication protocols, are based
on a _consistency check_.

Consider (ordinary) hash functions and message-authentication codes (MACs).
The function 'md5' from strings to strings is an example of an _unkeyed_ hash
function.

Example: Consider the RedHat web site.  Assume the web site is not compromised.
This web site might store both a patch 'p' and the 'md5' hash of 'p' (more
securely if these are not included in the same file).  The integrity check is:

 - download patch 'p'

 - compute md5 (p) = x

 - compare x with the downloaded 'md5' hash; does it match?

This is a simple message-integrity check.

Example: An unkeyed hash works much less well to guard the integrity of files
stored on a local disk when both 1) the adversary has read/write access to the
disk, and 2) the hashes of individual files are stored on the same disk.

Why?  If both the hash value and the file are stored on-line, there is a
simple attack.

 - Alice stores f, h(f)

 - bad guy modifies f to f', computes h(f') and stores f', h(f')

 - Alice's integrity check fails to alert her to the change

One solution is to store the collection of file hashes off-line.  This is
secure but perhaps inconvenient.

Digression: Since hash functions map spaces of high cardinality into spaces of
low cardinality, collisions occur (by the pigeonhole principle).  The only
claim made for a good hash function is that these collisions are
comptationally expensive to find.

Could we perhaps keep the hash function secret?  Yes, by using an MAC, which
is a _keyed_ hash function.  The idea is simple.
Consider:

  {m}k1 {h(m)}k2

But this is really:

  {m}k1 h(k2,m)

Now, you have to know key k2 to compute the same hash.  Alice can easily keep
key k2 in her pocket, i.e., off-line, much preferable to keeping 1,000 'md5'
hashes in her pocket.

There is a general principle here.  If you need a key for, say, an encryption
function and another key for, say, an integrity function, use _separate keys_
for each function.  This limits attacks compared to using the same key twice.

verifying a digital signature
_____________________________

Let us start with the basic idea in an impractical form.  (Impractical 
because of the high-cost of public-key operations).

Alice sends a message to Bob.  We use some notation:

  A --> B: A m {m}k-_A

Bob receives the message, notes the claim it is from Alice, and computes:

  {{m}k-_A}k+_A = m'

and then verifies that m = m'.  He can't do this unless he has a copy of
message 'm'.  Note that, in this simple example, no attempt is made to keep
message 'm' confidential.

But public-key operations cannot be applied to arbitrarily long strings.
Thus, it is more practical to write:

  A --> B: A m {h(m)}k-_A

Alice only signs a short string.  The verification procedure then has one more
step.  Bob retrieves message 'm', computes h(m) and also:

  {{h(m)}k-_A}k+_A = h'

and then verifies that h(m) = h'.

combining encrypting and signing
________________________________

One possibility (Alice sending to Bob) is:

  A --> B: A {m}k_AB {{h(m)}k-_A}k+_B

Alice uses a symmetric-key cryptosystem to encrypt message 'm'.  Encrypting
the digital signature is probably overkill; it can be sent in the clear.  This
got typed in this transcript more to make the point that signing should
precede encryption than because encryption of the digital signature adds value
in this context (it doesn't).  So, the following is safe:

  A --> B: A {m}k_AB {h(m)}k-_A

if we assume that k_AB is known _only_ to Alice and Bob.

certificate authorities
_______________________

We have spoken loosely that public keys are available from electronic phone
books.  But why should someone trust such a phone book?

Suppose there is a reputable certificate authority that issues digital
certificates affirming that the identity of entity A has been verified and
that the public key of A is indeed xyz!!123.

If you engage in a secure protocol with A, A hands you a certificate with his
civil name, his Internet name, and his public key.  You can read this.  If you
regard the certificate authority as reputable, then you have some trust in what
the certificate says.  But how do you know the certificate is not forged?

The certificate authority signs the certificate you received from A.  But now
you need the authority's public key to verify the authority's signature.
Logically, you need a certificate from a higher authority attesting to the
first authority's public key.

The new certificate must also be signed.  This new signature must also be
verified.  This leads to an infinite regress unless there is one "super
authority" whose public key is known to everybody.

Often, the certificate authorities are arranged in a tree-like hierarchy and
the name of the root authority is "dot".

A small group of people could get by with one certificate authority whose
public key is known out of band.  It is when groups of people grow extremely
large, change dynamically, and span multiple administrative domains that we
need to construct a public-key infrastructure (PKI).




  Previous message: [soen321-f04] week 7 material (Oct 14) 
  Next message: [soen321-f04] week 8 lecture material (Oct 26) 
  Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 


More information about the soen321-f04 mailing list