Aims and Means of Asymmetric Cryptography

 Usually  we tend to center the concept of Authentication to mere users, through and exhibited password as a credential

But beyond the user, how to be sure about authenticity of other assets? For example, how can we be sure about, once the user is authenticated, every received message, claiming in its header that it comes from his session is not a fake message created somewhere else (another user, a BOT, ...)? Even being originated from the expected user, what does guarantee us that the message wasn't change in its walk toward the server?

I'll explain this risk better: an always present threat in networking is the so-known Man in the Middle. Someone intercepts our message, filters it by changing sensitive parts (a transfer amount, a destination account, ...) and resends his altered version. The server receives it, and because it came from a proven identity session, it accepts it without noticing it was changed

How can we deal with this reality?

Public-Key Cryptography (aka Asymmetric-Key Cryptography) comes to rescue us. This algorithm works this way:

• The issuer, before sending his message, applies to it a function consisting in calculating a digest based on the message itself (a hashing value, a checksum, etc)
• This digest is encrypted by applying a key the sender owns, only. This key is well-known as the Private Key
• The encrypted digest is then added to the original message, together with a key the receiver will need in order to decrypt it. This new key, publicly available, is consequently known as Public Key
• The receiver, so, calculates the digest and compares his result with the decrypted received digest

Yes, the man in the middle could spy the message but he can't alter it in any way: if so he did, the digest would change and he doesn't have the private key to encrypt the new digest. So the conclusion is that every message, with both calculated and received digests matching, belongs to the original user and it's unadulterated. This algorithm, so, is useful to avoid two threats: message repudiation by the original user (for instance, after issuing a purchase) and tampering by anyone in the middle (to avoid message interception, there are another countermeasures)

Asymmetric-Key Cryptography examples are anywhere, even though we don't notice that. For instance, .NET's Code-Access Security (CAS) capability permits us, among lots of other features, guaranteeing that an assembly can't be replaced. How? Pretty easy:

• The assembly provider has his private key. Whit that key he digitally signs the assembly
• The assembly, that way, contains a digital signature based on its name, version and optionally culture information. This signature is encrypted with the private key and enclosed, together with the public key, into the assembly (which becomes a strong-named assembly)
• When, during execution time, the CLR loads the assembly in order to execute it, first it calculates the assembly signature based on assembly evidences (its name, etc). Then, with the enclosed public key, it decrypts the encrypted signature and compares it with the calculated one
• If they don't match, a SecurityException will be issued. Thus, in the case that anyone other than the original provider changes the assembly, be sure that the signatures won't match... with the solely exception of...
• Yes! Except the case the fake provider uses his own pair of keys (private and public). But .NET's security strategy prevents that thru the Microsoft .NET Framework 2.0 Configuration Tool (Administrative Tools) . That tool allows is to provide which public keys will be trusted
• That way, we just need to load there the public key of our trusted provider

Another example of Asymmetric-Key Cryptography usage, more agnostic, is present in WS-Security specification, applicable, for instance, thru X.509 certificates. This is available in Windows Communication Foundation (WCF) as well in the transient Web Services Enhancements (WSE) version 3

Finishing this article, I want to mention a variation of the Public-Key Cryptography, intended not for non repudiation purposes but for information disclosure avoidance. The variation consists in using -the sender- a public key to encrypt the whole message. The receiver, in this occasion, is the only who owns the private key, necessary to decrypt the message received. This variation avoids unauthorized inspection of incoming messages, but doesn't prevent spoofing of the sender identity