Download
1 / 41
410 likes | 529 Views
Public Key Certification Authorities. Public Key Certification Authorities. how to be sure you have the right public key for a particular principal A service is needed that will provide a binding between a principal's name and public key.
E N D
Public Key Certification Authorities • how to be sure you have the right public key for a particular principal • A service is needed that will provide a binding between a principal's name and public key. • In order to trust that this binding is correct, the service (henceforth referred to as the certification authority (CA)) signs the representation of the binding. • The public key for the CA is well-known, and therefore interested parties can ascertain that the signature is valid.
Public Key Certification Authorities • If the CA is compromised, however, there is obviously a problem • The private key for the CA should therefore be kept in a very safe place • unlike the KDC for secret key cryptography, the CA does not need to be online all the time • The CA has two functions: • certify bindings (i.e. certification) and • store the certificates. • Once created, the certificates can be stored anywhere and can even be procured (once signed) from an untrusted source.
Public Key Certification Authorities • What happens if a principal's private key is compromised? • all the certificates associated with that principal will cause the wrong public key to be used. • A solution is to insist that certificates have expiration dates • limits damage but doesn't completely eliminate it • KDC could have dealt with this problem just by deleting the KDC entry. Our problem with the CA is a direct consequence of not having the CA on-line all the time
Public Key Certification Authorities • We need a scheme to assert that a certificate that has not yet expired is no longer valid • A solution is to assign a unique serial number to each certificate and maintain a certificate revocation list (CRL) • A certificate is of the form: • {principal name, public key, serial number, expiration date}CA and • a CRL is of the form • {time of issue, revoked serial number, revoked serial number, . . .}CA.
Public Key Certification Authorities • A certificate is considered invalid if the expiration date has expired or the serial number of the certificate appears on a recent CRL • It is tempting to use the time of the message to compare to the expiration date, • but this is a bad idea. • An attacker that knows a compromised private key can use whatever time needed when creating a message (e.g. send a message that was sent "yesterday"). It is also important to use the most current CRL possible.
Public Key Certification Authorities • existence of CRLs requires that the CA or some other source of CRLs be online • Without access to a recent CRL, there is no way to know whether to trust a given certificate. • There are also some engineering tradeoffs that arise when using CRLs. • if the expiration time is small (not too far in the future), then certificates will be constantly reissued and lots of traffic will be generated. • Large expiration times lead to long CRLs. • If CRLs are issued frequently, then the amount of time vulnerable to compromise is short but lots of network traffic is generated. • If the CRLs are issued infrequently, then the possibility of compromise increases.
Public Key Certification Authorities • Having a single CA is unrealistic • There is no one entity that is trusted by everyone for everything (even in real life). • Performance will not scale well • A solution is to have multiple CAs. • The issue now becomes: • how does a principal in one CA's domain get a public key for a principal in a different CA's domain?
Public Key Certification Authorities • Imagine there is a user A in the CIA domain. Call the certifying authority CA-CIA. • Similarly, imagine there is a user B in the KGB domain and CA-KGB is the CA. • How can A communicate with B? A needs to know how to determine that a certification encrypted under CA-KGB's private key is valid. • Thus A needs the public key of CA-KGB. A receives {CA-KGB, PCA-KGB}CA-CIA from CA-CIA. It then receives {B, PB}CA-KGB from CA-KGB. If A trusts both CA-CIA and CA-KGB then A must conclude that PB is B's public key. • But what should lead Alice to believe that she can trust CA-KGB? • One solution is to have an agreed mapping from principal names to the name of the CA that is considered an authority on those names.
Logic of Authentication • For authorization, we are concerned with who makes requests and what they say. For example, Ahmet said “AB can read file X" or AB said "my public key is KAB". The general syntax is: principal said statement
Logic of Authentication • However, just because you say something doesn't make it true. Suppose AB said "the sun will rise today". Principal AB has no control over whether or not the sun will rise, so such a statement means nothing. If AB says "we will have a quiz in class today", however, then we have reason to believe that there will be a quiz, because we have this notion of authorities which looks likes the following (where -> is a meta-logical operator used to separate the hypotheses from the conclusion of an inference rule): P controls S, P said S -> S is true. When authorities make a statement about that which they are an authority of, we consider it as true. For example, we could have an authority on names and public key bindings (name <-> Kname): CA-A is an authority on A/*, or CA-A/B is an authority on A/B/*
Logic of Authentication • In a distributed system, what principals say can be altered in transit. • If we have a message m that is signed by some principal's private key, {m}ka, then • we know that KA said m (notice: we're now thinking of principals as either a person or a key, because whoever has that key can say it)
Logic of Authentication • We allow principals to speak for other principals. • If P speaks for Q, then (P said m) implies (Q said m). Whatever P said can be regarded as having been said by Q. Stated as one of our rules, • P speaks for Q, P said m -> Q said m. • So, we can have a Certificate Authority speak for another principal.
PEM -- Privacy Enhanced Mail • Privacy Enhanced Mail (PEM) is an example of a public key infrastructure • A problem with public key cryptography is knowing what is a suitable CA for a given principal. • The solution PEM employs is to tie CAs to the structure of the principal's name • There are two versions of PEM
PEM -- Privacy Enhanced Mail • In the first version, names are hierarchical (e.g. A/B/C/D). • An e-mail address such as bener@boun.edu.tr is represented as tr/edu/boun/bener. (In such a scheme, it is easy to add a new name uniquely.) • The PEM proposal is to have a CA for each subtree of the namespace. • That is, a CA named A/B/C is responsible for all names of the from A/B/C/* (where * is a wildcard.) • A CA named A/B is responsible for all names of the form A/B/*. • A rule for certificates is that the issuer of a certificate must be a prefix of the principal's name in the certificate. • That is, CA A/B can issue a certificate for A/B/C/D
PEM -- Privacy Enhanced Mail A can sign the public key of B, while B can certify the public key of A and of C.
PEM -- Privacy Enhanced Mail • A problem with the above scheme is that the CA at the root is too sensitive • Compromising A's private key in the above example would compromise everything below A • A new scheme was therefore proposed. • The root is the Internet Policy Registration Authority (IPRA) and • there are three classes of PCAs (Policy Certificate Authorities) below the IPRA. • The PCAs sign things. • The rule is that there is only one path in the hierarchy to any principal. • It is easy to find the path, and therefore easy to acquire the necessary certificates.
PEM -- Privacy Enhanced Mail There are three classes of PCAs: • High assurance -- Super secure with strict tests before issuing certificates to check identity. The same rules apply to all the CAs below the high assurance PCA in the subtree. • Discretionary assurance -- Well-managed at the top level, but no rules are imposed on organizations that are certified below the top level. • No assurance -- No statement can be made about the authority of this PCA.
Pretty Good Privacy (PGP) • Created by Phil Zimmermann • Selected the best available cryptographic algorithms as building blocks • Integrated these algorithms into a general-purpose application that is independent of operating system and processor and that is based on a small set of easy-to-use commands • Made the package and its documentation including the source code freely available via the Internet and bulletin boards and commercial networks such as AOL. • Entered into agreement with a company (network Associates) to provide a fully compatible, low-cost commercial version of PGP.
Pretty Good Privacy (PGP) • There are certificates in PGP, but each user is responsible for maintaining their own set of public keys on a key ring. • Users decide for themselves who to trust • How are the public keys acquired? • Keys can be sent signed by someone already trusted by the user. • Keys are initially acquired in person. • A chain of certificates is trusted if the user trusts every link in the chain, that is, believes that the signer gave the correct association of name and public key at every link
Pretty Good Privacy (PGP) • PGP asks each user to assign a "trust rating" to each public key that is on the user's public key ring • There are two parameters: • valid -- the user believes that the key is associated with whom the user was told it is associated with, and • trust -- a measure of how much the user trusts the principal as a signer. • The trust parameter is three-valued: none, partial, and complete
Pretty Good Privacy (PGP) • If a certificate is signed by a principal the user completely trusts, then that key is valid • If a certificate is signed by two partially trusted users, then again the key is valid • it is possible to devise very intricate trust management/key validity schemes.
Pretty Good Privacy (PGP) • What are good properties for inferring trust? • Should trust necessarily be transitive? • Should trust be monotonic (once trusted, always trusted)?
Pretty Good Privacy (PGP) Keys are generated in PGP as follows: • the user specifies the size of the key (in bits) and then • the user types a pass phrase. This pass phrase is then run through an MD5 cryptographic hash to obtain an IDEA key. The "private key" of the user is computed from the random timing in some typing that the user does. • The private key is then encrypted locally with the IDEA key that was generated. • having the private key always encrypted implies that if the computer was stolen, the private key is still secure.
Naming • A name is a form of abstraction that allows us to designate without details • Naming an object permits us to refer to that object without having to worry about the underlying details.
Naming Naming should possess the following properties: • The use of one name does not prevent other names from being used. • For example, naming a file in the current directory shouldn't prevent you from naming a file in some other directory. • If an object does not have a name, then it is not accessible. A name is the only way to denote an object. • Singular objects do not require names. • As an example, in uniprocessor machines, the single processor was unnamed and referred to implicitly. However, in multiprocessor or networked systems, each processor should have its own name.
Naming We can achieve several things by using names: • Sharing • Different entities can share an object through its name. • If there are two or more processes accessing the same object, they can set up names and use them to denote the object. In this case, each entity could use a different name for the same object. • Secrecy • Naming can provide secrecy. In a large name space, usually only a small fraction of possible names are used. Moreover, it is not obvious what this fraction will be. An entity that knows a certain name possesses knowledge that may not otherwise be available. • For example, computer passwords are typically chosen from a large set of unguessable character sequences, and provide a mechanism for secrecy. • Binding of names in programming languages also provide secrecy.
Naming: Concerns • ScalabilityIt is generally a bad idea in system design to assume that only a small number of names will ever be needed. Such an assumption is inherent in a fixed name size. For naming to be scalable, we need the following: • variable length names: The name space is potentially infinite. • unique names: The same name cannot be used to refer to two different objects. Duplicate names would preclude controlled sharing and secrecy. Verifying the uniqueness of a new name can be done by comparison against existing names and takes linear time. • no single central authority to produce names: At best, a single authority becomes a performance bottleneck, and at worst it is a single point of failure. Multiple entities should be able to check a name against existing names for uniqueness. • a manageable cost to produce new names: A distributed linear algorithm is usually not good enough.
Naming: Solution • hierarchical naming • indefinite growth in both directions: • For example, we can add either area codes or extensions to expand phone numbers. • distributed authority to create names: • For example, one authority would be in charge of names beginning with a/b/c, while another would be in charge of names beginning with a/b/d. • As long as each authority maintains the uniqueness of names within its assigned sub-domain, we will have global uniqueness of names.
Naming • we need more information about an object than only its name • names accompanied by hints: We must be able to access hints for a given name, and, if the hints are stale, we must be able to correct them. • impure names: A name is pure if there is no content in the name. • An impure name contains attributes of the object it names. Intuitively, impure names are great, since we can easily extract necessary information from the name itself. • On the other hand, impure names have a built-in consistency problem; when the information is no longer correct, the name must change. A mechanism is required for changing names.
Naming • In the past, there had been considerable discussion in the network community regarding a distinction between names, addresses, and routes. • This distinction actually turns out to be a non-issue. • By conventional wisdom, • a name designated an entity, • an address denoted its location, and • a route described how to get to that location
Each Ethernet card has a unique address, and it was common to use the card attached to a processor to name the processor. The naming fails, however, when two cards are attached to the same processor, for then, there is the illusion of having two processors. The two cards provide names, routes and addresses for one CPU and the distinction is no longer useful.
Binding • Names are a way of denoting something, and associated with each name is an object. This association is called a binding • The mapping is partial. Consider the use of names for secrecy: only a small fraction of the name space is used. • The mapping is subject to change, although it happens slowly and infrequently. E.g., after a file is edited, the same file name now refers to a different bit stream. • The domain of the context is interesting. That is, it may be useful to determine what is in the domain. We enumerate the names in a domain or sub-domain when we need to create new, unique names.
Binding • A simple example of a context is memory. Memory essentially associates with each address (name) a value • Where are these contexts? Generally speaking, names must acquire meaning in one of the following ways: • Names can have a meaning in a universal context. For example, a country code followed by a national phone number is a universal context, under the presumption that calls to Mars do not occur. • Names could be accompanied with the name of the context within which to evaluate the name. (For example, working directories for unqualified file names.) • We could assume (ensure) that whoever evaluates the name will use the same context as whoever sent the name. This can lead to unfortunate situations, however.
Binding • Context is another way in which to enforce security. • For example, the name "write" may be bound to different things for different users depending upon their privileges. • Context is thus also a form of protection.
Implementation of Hierarchical Naming • how to manage binding? • If there is no structure associated with a particular name then a global service is necessary. • It makes more sense to regard a name such as /a/b/b as a list of simple names and implement it using a tree.
Implementation of Hierarchical Naming the name a/b/b denotes a leaf object and circles represent directories or contexts. A hierarchically-structured name can be regarded as defining a path in the tree.
Implementation of Hierarchical Naming • What if we are trying to merging two organizations, effectively extending names to the "left"? By simply merging, we create a new root node, and make the two original trees its left and right children respectively. The trouble is that none of the old names will work anymore. We need a way to "jump" over parts of the tree, to equate the value of a name in a directory with the value of another name in another directory.
Implementation of Hierarchical Naming • A solution is to provide a mapping from the path in the old names to paths in the new names. • When we see an old name starting with a we map it to ibm/a. Similarly, b is mapped to ibm/b, c to dec/c, and so on. • This technique works provided that we have no duplicate names between the original two trees. • the naming trees can actually be merged at any level
