Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

Comments and feedback inline.



Before going into further detail on how to create technical solutions to
solve all these interesting challenges, we (CAcert) probably first have
to decide whether CAcert will require some kind of dual control, or is
happy with changes being made a single individual without formal
approval or audit by another person.

So, who feels that it is acceptable for a single individual to "have the
keys to the vault"?
Do we need dual control on critical infrastructure elements and key
access?



Lambert Hofstra  

> -----Original Message-----
> From: 
> cacert-policy-bounces AT lists.cacert.org
>  [mailto:cacert-policy-
> bounces AT lists.cacert.org]
>  On Behalf Of Kyle Hamilton
> Sent: 20 February 2006 15:13
> To: Policy-Discussion
> Subject: Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control
> Specification
> 
> 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.
[Lambert Hofstra: ] 
I'm cool  :-)
> 
> > 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.)
[Lambert Hofstra: ] 
"m of n", with m=2 and n=4.  Often used for recovery, however, I don't
know if OpenSSL supports this (I'm not a OpenSSL expert).

Next issue is: how would you be able to enter the key when you're 20000
km away from the server?. Not impossible, but one would have to think of
a solution.

> 
> > > 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?)
[Lambert Hofstra: ] 
Correct. Either have a "m of n" solution, or have backup custodians.
Having a "m of n" solution would, as you describe, allow for multiple
levels of security (m being 2, or 3 for more critical actions)

> 
> > >
> > > 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.)
[Lambert Hofstra: ] 
This is a good and cheap solution. I see we're thinking in the same
direction here.
You could use a SSL tunnel with mutual authentication (for the secure
transmission), and a protocol with a manual "anti replay" protocol,
where the reviewer sends a code, and the sysadmin has to respond with a
modified code and write it.

This is of course only a way to log a change, and confirm that a change
actually was performed. It does not prevent the sysadmin to make another
change than agreed.

Lambert

> 
> -Kyle H
> _______________________________________________
> Have you subscribed to our RSS News Feed yet?
> 
> CAcert-Policy mailing list
> CAcert-Policy AT lists.cacert.org
> http://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy