Policy-Discussion

["Kyle Hamilton" <aerowolf AT gmail.com>]

See comments inline.

On 2/20/06, 
Lambert.Hofstra AT ins.com
 
<Lambert.Hofstra AT ins.com>
 wrote:
> > The security versus availability tradeoff: encrypt the backups with
> > the public portion of that keypair.  If a backup needs to be restored
> > for any reason, the operator in Australia has one of two halves of the
> > key necessary to unlock the backup, which enforces an auditable event
> > because at least one of the other employees will know about the event
> > and have to contribute his share.
> [Lambert Hofstra: ]
> ?? This will not work: who would have the private key that is needed to 
> decrypt? I hope not a single individual!

We're talking about the same thing, just using different language.  Calm down.

> What is often used, is splitting the decryption key (symmetric or 
> asymmetric) into key components, that can be combined by XORing all key 
> components. This way each component will still be full key length, but 
> useless in itself. Components can be guarded by key custodians, so you'd 
> need all custodians to build a decryption key. Since a custodian should 
> have no role as sysadmin (does nothing directly with the system, preferably 
> have limited IT knowledge), he/she could be anyone in the company.

...ummm... that's precisely what I was proposing, except I was
operating on the assumption that any 2 of the 4 officers could
authorize the decryption of the backup.  Thus, the private key would
be split by a 2/4 secret splitting mechanism.  The person in
Australia, who has the physical access, would have one of the two keys
necessary.  He would have to contact one of the other three people
('key custodians') in the company who have key shares in order to get
a second piece of the key to reconstruct the private key. (and the
second piece of the key might even not have to go into his hands, if
it could be partially decrypted by one of the keys and then have the
decryption finished at the server site.  That would entail having the
backup sent over the 'net, but through a strongly-authenticated TLS
tunnel that shouldn't be too bad.)

This would ensure that at least one of the other officers of the
company knew that the sysadmin wanted to decrypt the backup, and be
able to ask "why?" and share the information with the other officers
and the public as needed.  No single person could act alone.

(And the reason for the 4-way key split is so that the individual
shares used to reconstruct the key would also be individually
identifiable, and thus individually auditable.)

> > As well, I'd recommend the practice of using the root keys to sign
> > intermediate, shorter-term CAs.  This will reduce the amount of
> > plaintext which is encrypted with the CA key, making known-plaintext
> > attacks (not that I know of any against RSA, but y'never know) less
> > possible, and mitigating the risks thereof in any case (if an
> > intermediate CA is compromised, you can revoke that CA's certificate
> > (and thus all of the certificates it signed) without having to place a
> > new root certificate in every RP's software.
> [Lambert Hofstra: ]
> I agree. It would also allow changes to intermediate CA's by a single 
> individual (for now, not as permanent solution), but still make it 
> mandatory for dual control required for all changes to the root CA.

It would also make it possible to encrypt the root CA key with a 2/4
or 3/4 secret share, so that the creation of a new subCA (and the
revocation of any subCA) would require more than a single person -- a
'ceremony' would have to be performed.  (The reason why 2/4 or 3/4:
massive timezone differential, and what if someone has a heart attack
or gets hit by a bus?)

> >
> > In accounting and security both, "separation of trusted duties" is
> > fairly critical.  I understand the limitations that CAcert faces, and
> > those limitations need to be addressed in the resulting document
> > itself.  ("Security best practices dictate that these functions be
> > performed by separate individuals.  However, due to only one person
> > having access to the physical hardware at this time [due to distance
> > concerns], these actions are all performed by the same person:
> > <enumeration>.  At such time as more individuals are employed by the
> > CAcert Foundation, these duties will be split up according to industry
> > best practice, and an update to this document will be issued.")
> [Lambert Hofstra: ]
> I'd still prefer some kind of dual control. This could even be something 
> stupid like the requirement to monitor changes via a webcam: although the 
> reviewer would not be allowed to see what the sys admin is actually typing 
> on the keyboard, the reviewer could log the implementation of a change on a 
> specific date and time, by a specific individual (the sysadmin). This could 
> then be matched with a change request, and the log of the sysadmin.

So would we all, but logistics tend to make it difficult, if only
because of massive timezone differences.  (A webcam can easily be
defeated unless there was a specific protocol for its use -- for
example, the sysadmin and the authorizing person agree on a date/time,
and a set of codewords for a given interaction with the system.  The
sysadmin writes those codewords in big block letters with a marker on
a piece of paper, and holds it up as he enters the room, with the
person authorizing the change [well, preferably, someone else]
recording the session and then signing and timestamping it.)

-Kyle H