> On Fri, 28 Mar 2008 19:09:52 +0100, Frans Bouma <[EMAIL PROTECTED]> wrote:
>
> >> What you don't want: the key used for signing is available to anyone who
> >> installs your client, so Bans Frouma can get at it and use it in his Pi
> >> Komputing Klient.
> >
> > So that's a typical client-side certificate SSL connection. THe TS
> > should read into that how that's done with public/private keypairs.
>
> Even so, the private key used to decrypt messages from the Pi Computing
> Service (and sign messages to it) has to be accessible to the client, right?

        no, that's the beauty of public/private keys :) The client encrypts
the initial connect with the public key in the certificate it has. The service
has the private key, and can decrypt it.

        Though no matter what's invented here, the main point is that whenever
you have a 'secret' that is shared among a small group of processes, if a
process wants to access the secret, it has to authenticate itself as an
element that has access to the secret. You can't avoid that. So if a process
can authenticate itself as a legitimate element, your secret has to be shared
with that process.

        One could do a 2 step process though: processes which have access
receive a certificate, issued by the secret keeper. Also, the process has an
id. The process encrypts the id with the certificate, and the secret keeper
decrypts that with the private key. If that decryption process succeeds: the
certificate is valid. If the ID exists in the list of ids of processes which
have access, the process has to be given access.

        client-side certificate SSL is a bit more complex but works similar to
this (but encrypts different data). It's all about authentication. So if that
mofo Frouma gets his dirty hands on a certificate, he can connect to the
service, but if he doesn't have a valid id, he still can't use the service and
access the secret. Though if he has a valid id, there's nothing that can stop
him, as he identified himself properly.

                FB

===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to