It easy to get lost in the hype regarding X509 certs. Most things these days talk about X509 certs and using them for security. However, I am not as impressed from a security perspective. The underlying PKI is secure (as PKI can be), however in some ways it is not safer then requiring another password. Most systems using certs require a password and some form of digital signature using the private key and encryption using the public key. So that is supposed to be two levels of protection – something you "know" (the password), and something you "have" (the cert). However, a cert can be copied and used on any computer. So it is not "really" something you have, because anyone can have it. It can be copied and sent around. If I have your password and your cert, I can act as you. So a cert is really just another string of bytes I need (i.e. another password). So if someone in your org is a target then there are many ways to get this info. Most times the hacker is inside the org as those people have the most knowledge of the systems (e.g. the Inside-Job). Think about it, how many people get on your computer and install software or fix issues? Most times they are logged on as you or have Admin rights. A small little program can be run to grab your cert(s) and put them to network storage or floppy at the desk. Now they probably ask for your password so they can log back in after the screen saver pops. Or as they may have access to the cert private key, they can grab passwords off the wire. In fact, they probably have collections of user certs stored in a server so they have access to them if/when your machine needs a new image. So certs are easy to get from help desk, sys admin, or DBA staff. So there are a lot of ways to get your cert(s). And once I have your cert, I probably have it for a long time, as they don’t get changed much.
Therefore, I argue that std RSA PKI with dynamic symmetric shared keys may be a better option for these reasons:
1) They are as strong as PKI and AES (the same thing certs use).
2) They don’t require purchase or distribution.
3) The symmetric key is generated dynamically and not stored anywhere. It changes per session.
4) The symmetric key is not generated from cert info, but random.
5) Because they are free, it can be easier to change them out more often (i.e. every 30 days) using some automatic method.
6) You don’t care if someone takes my public RSA key on my computer. It is public.
So in .Net ville, that may look something like:
1) Service has RSA private/public key pair (no certs). This must be secured.
2) Clients have RSA Public key of server. This could be the public Strong Name (SN) key signed on an assembly or other out-of-band methods.
3) Client generates random symmetric key, encrypts via RSA and sends to server.
4) Server decrypts symmetric key using RSA private key.
5) The server replies with some *signed reply acknowledging key. The msg is signed with server’s private RSA key.
6) The client verifies signature and continues only if good.
7) Client and Server now have a encrypted session using shared symmetric key. Key is not stored anywhere past the session and changes each time new session is started. There is nothing to steal (except the password from the user’s head).
So the server can verify client using encrypted username and password over the secure channel. And client can verify that only the owner of the private key (i.e. our server) is at the other end and not a man-in-the-middle.
This is pretty much how SSL and WSE SecurityContextToken service generate shared keys. However they require X509 certs. The method above does not. They major difference replacing certs with std RSA PKI. I will post my own SCT service using this method shortly. Comments?