Patterns: authentication

The server generally authenticates to the client by its SSL certificate. One very popular way of doing this is to have the client trust a well known authority, a certificate authority (CA) and then verify that the name of the server’s certificate matches expectations, and that the server’s certificate is signed by the CA and not yet expired. This is an excellent method if previously unknown clients do drive-by connections to the server, but has no real value if all the clients are pre-approved for a particular service on a group of particular servers. In that case, it’s just as easy, much cheaper, and arguably more secure, to provide all the clients with the server’s public certificate ahead of time, during installation, and let them verify the server certificate against that public key. 

But how do we authenticate a client to the server? Well, we provide the server with the client’s public key during installation and then verify that we have the right client on the line during connections.

We could let the client authenticate against the server using the built-in mechanisms in HTTPS, but the disadvantages of that are numerous, not least of which is getting it to work, and maintaining it over any number of operating system updates. “Fun” is not the name of that game. Another major disadvantage is that the protection and authentication that comes from the HTTPS session are ephemeral; they don’t leave a permanent record. If you want to verify after the fact that a particular connection was encrypted and verified using HTTPS, all you have to go on are textual logs that say so. You can’t really prove it.

What I’m describing now is under the precondition that you’ve set up a key pair for the server, and a key pair for the client, before time and that both parties have the other party’s public key. (Exactly how to get that done securely is the subject of a later post.)

Step 1

The client creates a block consisting of:

  • A sequence number, which is one greater than the last sequence number the client has ever used.
  • Current date and time
  • Client identifier
  • A digital signature on the above three elements together, using the client’s private key

The client sends this block to the server.

Step 2

The server (front-end) then uses the client identifier to retrieve the client’s public key, verifies the signature, and checks that the sequence number has never been used before. The server also checks that the date and time is not too far in the past or the future. 

If everything checks out fine, the server records the session in the database and updates the high-water mark (last used sequence number from this client).

Step 3

The server creates a block consisting of:

  • The client’s sequence number
  • Current date and time
  • Client identifier
  • Server identifier
  • A digital signature on those elements together, using the server’s private key
This block is then sent to the client, allowing the client to verify the signature, and save the record to its own local database. Since the block contains the client’s sequence number, which needs to match, it cannot be a playback.


Doing it this way creates a verifiable record in the database about the authentication. The signature is saved and can be verified again at any time. This allows secure non-repudiation.

Creating the authentication as a signed block also means that the client does not necessarily need to communicate directly with the server. If a client needs to deliver documents to another system, which in turns forwards them, it can also deliver the authentication block the same way. The forwarding system does not need to hold any secrets for the actual client to be able to do that. This allows us any number of intermediate message storages, even dynamically changing paths, with maintained authentication characteristics.

I should also note that doing the authentication this way decouples the mechanism from the medium. If you replace HTTPS connections by FTP, or even by media such as tape or floppy disks (remember those?), this system still works. You can’t say the same of certificate verification using HTTPS.

Leave a Reply

Your email address will not be published. Required fields are marked *