Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

See comments inline

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 12:44
> To: Policy-Discussion
> Subject: Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control
> Specification
> 
> 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!
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.

> 
> 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.

> 
> Anything that is done with the hardware configuration, the network
> configuration, the software configuration, any usage of keys -- all of
> this needs to be auditable, and thus logged.  The system administrator
> should NOT have access to these logs, and these logs should also be
> encrypted as new log records come in.  Once every so often, the
> auditing officer (who has the private key necessary to decrypt the
> logs) gets the file from the system administrator.  If the logfile is
> corrupt, assume that the CA has been compromised.  (The modifications
> to system, software, and network need to be written down, and the
> paper logs copied and sent to the auditing officer.)
> 
> Also, even though the backup media is encrypted, you need to specify
> what conditions it's kept in (a safe deposit box?  A fire safe at the
> home of the system administrator?  A safe in an access-controlled
> facility?), as well as how often the backups are tested and how long
> they're retained.  As well as how the media is zeroed before allowing
> new backups to be put on it.
> 
> 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.


> 
> (I wasn't talking about CA keys being generated on a 2/4 basis --
> rather, access keys to auditable functions, such as generating sub-CA
> keys in accordance with my recommendation above, or signing such.)
> 
> Just some thoughts. :)
> 
> -Kyle H
> 
> On 2/20/06, Philipp Gühring 
> <pg AT futureware.at>
>  wrote:
> > Hi,
> >
> > > This makes me wonder if it would be possible to have a key generator
> > > somewhere that would split it into a 2/4 share scheme before ever
> > > letting it leave the box -- preferably one that would do all the
> > > encryption necessary to send via S/MIME to each of the employees, as
> > > well as talking to the SMTP server to do so.
> >
> > The certificate machine is nearly completely offline, has no network
> stack on
> > it, there is no SMTP there ...
> > The keys on it only leave the machine on encrypted backup media.
> >
> > But perhaps 2/4 shared encrypted backups are an idea.
> >
> > The question is, whether it really helps in the end.
> > (Security vs. Availability tradeoff)
> >
> > Best regards,
> > Philipp Gühring
> >
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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