[linux-elitists] System-wide certification key (equivalent of root access)

Jason Spence thalakan@lightconsulting.com
Fri Jan 18 12:30:21 PST 2002

On Fri, Jan 18, 2002 at 10:53:17AM -0800, Seth David Schoen developed
a new theory of relativity and: 
> I was thinking about the possibility of having a public key or keys
> which would be kept in a world-readable file in /etc (for example,
> /etc/system-signing-key or /etc/certification-keys) and used to verify
> signatures on various things on a system.  Something which was
> properly signed with that key would be implicitly trusted (by any
> software which was written to be aware of this mechanism), so that
> the ability to sign with that key would be equivalent to having root
> access.  (The principle would be that anyone who's capable of
> generating a fake signature with the certification key would also be
> capable of replacing any binary on the system with a fake version, so
> this should introduce no new security risks if the key is kept at
> least as secure as the root password.)

I've been thinking a lot along the same lines lately, especially with
regards to LDAP and the public key distribution infrastructure.  

See, there was once a telephone company named Ma Bell.  Ma Bell had
lots of friends in Europe and Asia who had these things called phone
directories which had lots of numbers in them.  You could (and still
can) use them to figure out the number of someone you wanted to call
if you didn't know it.

Ma Bell wanted to spend lots and lots of money on a new computerized
telephone directory, which she called 'THE directory', or X.500.  So
they went the standards route and hooked up with the OSI folksen and
way way overengineered this directory.  

Fast forward about 10 years...

So the University of Michigan has this implementation of DAP, the
directory access protocol for X.500, right?  They hacked up a TCP/IP
version of the protocol for running over non-OSI networks, and
suddenly no one using DAP anymore, all the UofM directory sites are
using this new LDAP thing for searches.  

Then Verisign says "hey, this sucks a lot less than the WHOIS
protocol" and their research department comes up with
ldap.research.netsol.com, and they're pushing other registrars to use
it for domain info instead of WHOIS.  They'll even put in a SRV record
pointing to your LDAP server if you ask them nice. 

What's the point?  Well, how do web browsers deal with the PKI issues
necessary to validate the identity of an SSL site which just hands
them a certificate?  They have the hierarchy of root certificates
built in which are implicitly trusted, right?  Well, why doesn't ssh
have the same thing, except it can actually go out and validate it?

 - SSH gets public keys for several root LDAP servers built in.

 - Alice wants to ssh into Bob's server which she's never talked to

 - Alice's copy of SSH contacts Bob's server and receives Bob's
   servers public key, which is signed by Verisign (or the Debian
   people or whoever).

 - Alice's copy of SSH contacts one of the global LDAP root servers
   using SSL and gets a referral to Bob's company's LDAP server.  This
   is a trusted connection and we know it's not spoofed because
   Alice's copy of SSH has public keys for those root servers built in
   already.  She also gets a fingerprint of Bob's key (or the whole
   public key maybe) too.

 - Alice's copy of SSH contacts Bob's LDAP server and verifies that
   the public key that his server hands out matches the fingerprint
   (or public key) that the global LDAP root server handed out.

 - Alice negotiates a SSL connection with Bob's LDAP server and gets
   Bob's public key (which may or may not be signed by others).  

 - Alice then resumes talking to Bob's SSH server and gets Bob's
   server's SSH key.  It's supposed to match the one that she just got
   from Bob's LDAP server.  If so, then she's definitely talking to
   one of the people who have control (or talk to the people who have
   control) of Bob's domain info.

Now, that's just one way you could deal with the PKI distribution
issues we have with SSH.  SSH2 isn't very vulnerable to
monkey-in-the-middle attacks, but it's still bad bad bad that everyone
just whacks the y key (especially when we're working remotely) when
their SSH client says "hey, this key doesn't match the one I got last
week...".  This is one solution, although it adds plenty of latency to
an already laggy way of connecting to a server.

The answer to the verification latency is signed keys.  The above
verification protocol works great if you don't want to pay for a
signed key and are willing to deal with the latency issues for
verifying the key.  Someone like sourceforge who has lots of anonymous
people out there connecting to their boxen via SSH would want a key
signed by a major PKI vendor like Verisign, because then everything
just works (since the Verisign key is trusted by most versions of
SSH).  Another company which just has employees connecting to their
boxen would just set up a self-signed root key and hand it out to all
the employees via a trusted channel like Fedex or having them in the
office.  Then you have a master key for the org which signs the system
keys, so you only have to add one master org key to your list of keys
to trust.

This also allows you to yank the keys really fast, because you can
just talk to your LDAP server and post an entry that says "hey, I'm
yanking this key because of reason code 02 (massive break-in), so
pop up a big fat warning if you connect to a system that's using that
key, ok thanks and here's the new one."

Another idea: if Seth's idea is implemented, but the private keys are
kept on a floppy or CF card or something, then you can get SECURE
SYSLOG!  The admin walks up to the server every month/week/day/shift
and checks to see if it's been broken into or the data tampered with.
If not, he sticks the private key into the system and uses it to
encrypt'n'sign the syslogs, then a script uploads them to a secure
filestore somewhere.  Or it's totally automatic for every syslog
packet so that the intruder can't spoof new ones after they've logged
in because they don't have access to the key in memory and /dev/kmem
(is supposed to be) locked down.

Because seriously, the k1dd3s figured out how to edit syslog files a
long time ago, ok?  Patch your syslogd to forward stuff to a host that
isn't in syslogd.

Thinking about the filesystem-level stuff, I just realized that
kernels basically have a line in a lot of syscalls that looks like,
well, go look at fs/*.c, ok?  Well, instead of that simple comparison
logic, you have to do crypto now to figure out whether to return
-EPERM or 0.  You could cache things, but I still think there would be
a bit of a performance problem, especially since some of those
permission-related syscalls are called several bazillion times during
a ls -R, say.  Oh, and getting read-only access to /dev/kmem is now
equal to root access.  That's not a huge problem, though, since
everyone assumes that /dev/kmem read and/or write is reserved for
root's eyes only.

And writing to disk involves a whole bunch of non-cachable crypto ops,
which will slow things down a whole lot.  Multiple byte-by-byte
read/write passes over every block of data that needs to be written if
you're encrypting all the data.  Although you could just sign the
inode... hmm.

 - Jason

"I'd love to go out with you, but I have to floss my cat."

More information about the linux-elitists mailing list