Re: General PKI Question
lynn_at_garlic.com
Date: 05/20/05
- Next message: Roger Abell: "Re: Security? Right."
- Previous message: Roger Abell: "Re: Local Users Group - Safefly removing users ?"
- In reply to: Ted Zieglar: "Re: General PKI Question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 20 May 2005 08:47:21 -0700
Ted Zieglar wrote:
> First, a bit of background: If you want to send an encrypted message,
you
> encrypt the message with the intended recipient's public key. That
way, only
> the intended recipient can decrypt the message (with their private
key).
>
> If you want to send a signed message, you encrypt the hash of your
message
> with your own private key. If the recipient can decrypt the hash with
your
> public key, that proves that the message came from you.
>
> Now to your question: Where does one obtain someone's public key?
Well,
> there are several methods but in general it works like this: If
you're
> encrypting a message your software obtains it from a PKI. If you're
signing
> a message your software will attach your digital certificate to the
message.
> The digital certificate contains your public key.
basically there is asymmetric key cryptography as opposed to symmetric
key cryptography. in symmetric key cryptography, the same key is used
for both encrypting and decrypting the same message. in asymmetric key
cryptography they are different keys.
a business process has been defined for asymmetric key cryptography
where one key is designated as "public" and divulged to other parties
and the other key is designated as "private" and is never divulged.
some additional business processes have been defined
1) digital signature authentication .... a secure hash is computed for
the message, which is then encoded with the private key. other parties
with the corresponding public key can decode the digital signature and
compare the decoded secure hash with a freshly computed secure hash of
the message. this will validate a) the origin of the message and/or b)
if the message has been modified.
2) confidential data transfer ... people will encode messages with the
recipient's public key. only the recipient with their (never divulged)
private key can decode the message. frequently because of overhead of
asymmetric key cryptography ... a random symmetric key is generated,
the message is encrypted with the symmetric key and the symmetric key
is encode with the public key.
The encrypted message and encoded symmetric key are transmitted
together. only the corresponding private key can decode the symmetric
key ... and then, in turn decode the actual message.
In general, public keys can be registered with other parites ... in
much the same way shared-secrets and other kinds of authentication
materials are registered today ... using well established business
process relationship managment processes (some that have evolved over
hundreds of years, like bank accounts).
The initial kerberos pk-init ietf draft for adding public keys to
kerberos implementations specified registering public keys in lieu of
passwords
http://www.garlic.com/~lynn/subpubkey.html#kerberos
later specifications were added that certificate-based public keys
could be used
There have also been RADIUS implementations where public keys were
registered in lieu of passwords and digital signature authentication
operation was performed
http://www.garlic.com/~lynn/subpubkey.html#radius
>>From 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor
* something you have
* soemthing you know
* something you are
digital signature authentication schemes are a form of "something you
have" authentication .... only you have access and use of a (never
divulged) private key.
Certificate-based public keys (PKIs) were designed to address the
offline emails scenario of the early 80s; recipient dials up their
(electronic) postoffice, exchanged email, and hungup. They were then
possibly faced with some email from a total stranger that they had
never communicated with before.
Certificates were somewhat the "letters of credit" analogy (from the
sailing ship days) ... where the recipient/relying-party had no other
means of obtaining information about the subject ... either locally (or
heaven forbid using online, electronic means).
In the early 90s, there were x.509 identity certificates ... where the
CAs, not being able to reliably predict what information some future
relying party might need .... were looking at grossly overloading
certifictes with excessive amounts of privacy information. Later in the
90s, some number of infrastructures (like financial institutions) were
realizing that identity certificates, grossly overloaded with excessive
amount of information represented significant liability and privacy
issues.
At this time, you saw some appearance of relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
where the information in a certificate was reduced to little more than
a record lookup indicator (userid, account number, etc). a person would
create a message, digitally sign it, and package the message, the
digital signature and the certificate and send it off to the relying
party. the relying party then would use the indicator in the base
message to index the appropriate relationship record and retrieve the
associated information (including the registered, onfile public key).
the onfile public key would then be used to verify the digital
signature (authenticating the messsage). It was trivial to demonstrate
that the stale, static certificate was redundant and superfluous.
in the financial sector, these relying-party-only certificates were
also be targeted at payment transactions. the typical payment message
is on the order of 60-80 bytes. the typical relying-party-only
certificate from the period was on the order of 4k-12k bytes. not only
were the stale, static certificates redundant and superfluous, but they
could also contribute a factor of 100 times in message payload bloat.
a basic issue is that the certificate design point was addressing the
problems of a offline, unconnected world for first time communication
between total strangers. as the world transitions to ubiquitous,
online, certificates are looking more like horse buggies on an
interstate with 75mph speed limit.
we were asked to do some consulting with this small client/server
startup in menlo park that wanted to do some payment transactions on
their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and they had this thing called SSL that could encrypt internet
transmission.
slightly related, recent posting
http://www.garlic.com/~lynn/2005h.html#39 Attacks on IPsec
there was also a perceived integrity problem with the domain name
infrastructure ... so SSL server domain name certificates were defined
http://www.garlic.com/~lynn/subpubkey.html#sslcert
where the browser would compare the domain name in the typed-in URL
with the domain name in the digital certificate. Along with working on
the specifics of payment gateway ... we also got to go around and do
end-to-end business audits of several of the certification authorities
that would be providing SSL server domain name certificates.
The process has an applicant for an SSL server domain name certificate
providing loads of identification information. The certification
authority then performs the expensive, complex, and error-prone
identification matching process of checking the supplied identification
material with the identification material on file with the
authoritative agency for domain name ownership.
Note that the authoritative agency for domain name ownership is the
same domain name infrastructure that has the integrity issues that give
rise to the requirement for SSL server domain name certificates.
So somewhat from the certification authority industry, there is a
proposal that SSL domain name owners register a public key at the same
time they register a domain name ... as part of an attempt to improve
the integrity of the domain name infrastructure (so that the
information that goes into certification of SSL domain name
certificates is also more reliable).
Now, somebody can digitally sign their SSL domain name certificate
application. The CA (certification authority) can now retrieve the
onfile public key from the domain name infrastructure to validate the
applicant's digital signature ... note this is a certificate-less
digital signature authentication using online, onfile public keys
http://www.garlic.com/~lynn/subpubkey.html#certless
this also has the side-effect of turning an expensive, complex, and
error prone identification process into a simpler and more reliable
authenticatin process.
However, this improvement represents something of a catch22 for the CA
PKI industry ...
1) improvements in the integrity of the domain name infrastructure
mitigates some of the original requirement for SSL domain name
certificates
2) if the CA PKI industry can make the trust basis of their whole
infrastructure on certificateless, real-time retrieval of onfile public
keys .... it may occur to others that they could use the same public
keys directly
(potentially modifying the SSL protocol implementation to use public
keys directly obtained from the domain name infrastructure rather than
relying on stale, static certificates).
- Next message: Roger Abell: "Re: Security? Right."
- Previous message: Roger Abell: "Re: Local Users Group - Safefly removing users ?"
- In reply to: Ted Zieglar: "Re: General PKI Question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
