The Fraud Prevention Source

Public Key Authentication

'Shared secret key' cryptosystems have traditionally been used to authenticate or verify information when only two parties are involved - usually a creator of information and an authenticator of that information. For example, if a check issuer created encrypted (scrambled) information from each check's payment instructions and printed that information on each check, then the paying bank, during authentication, could verify or authenticate the payment instructions with the encrypted information before paying checks presented for payment. The check issuer and paying bank would use the same 'shared secret key', which was known only by them. See Ethent Views: " Shared Secret Key Authentication" for a more detailed discussion.

However, if a number of authenticators knew a 'shared secret key', then there would be substantial risk that one or more of those authenticators would use the 'shared secret key' to create counterfeit encrypted information. This counterfeit encrypted information would pass the authentication tests, because it would have been created with the same 'shared secret key' used to authenticate or verify the encrypted information. Thus, 'shared secret key' cryptosystems are not practical in situations where there are multiple authenticators who know the 'shared secret key'.

'Public key' cryptosystems, on the other hand, are ideally suited for situations where there are multiple authenticators because the 'public key', used for authentication, cannot be used to create encrypted information that will pass the authentication tests. Only the 'private key' can be used to create encrypted information that will pass the authentication tests.

Now let's take a closer look at how 'public key' cryptosystems work and how they can be used for authentication.

Public Key Cryptosystems

The limitations of 'shared secret key' cryptosystems had long been recognized and various solutions had been proposed over the years. None looked practical, however, until the 1970s when the notions of key splitting and a "hard problem" began to emerge as a significant enhancement or option to 'shared secret key' cryptosystems.

The basic idea was to split the 'shared secret key' into two parts or create two separate but related keys. The relationship would be such that if one key (for example key #1) scrambled or encrypted information, then the other key (for example key #2) could unscramble or decrypt the scrambled or encrypted information and return the information to its original form.

Two important requirements were:

Key #1, the encrypting key, could not decrypt 'encrypted information' and return the information to its original form. Key #2, the decrypting key, could not encrypt information and create the same 'encrypted information' as key #1.

At some point most mathematicians began to call the encrypting key the 'private key' and the decrypting key the 'public key'.

At first glance it would appear, because there is a relationship between the private and public keys, that it would be easy to calculate the 'private key' from knowledge of the 'public key', encrypted information and the original unencrypted information.

This is where the concept of a "hard problem" comes into the picture. Mathematicians have developed 'public key' cryptosystems, where the 'private key'/'public key' relationship is such that a "hard problem" must be solved before the 'private key' can be calculated from knowledge of the 'public key', encrypted information and the original unencrypted information.

Well known 'public key' cryptosystems, like RSA and DSA, have been developed around either of two "hard problems" - one based on the mathematical properties of prime numbers and the other based on the mathematical properties of discrete logarithms. Using either of these systems and with knowledge of the algorithm, 'public key', encrypted information and the original unencrypted information, it would take many, many years and extensive computer resources to calculate the correct 'private key'. This is because the "hard problem" must be solved before the 'private key' can be determined.

Since knowledge of a 'public key' does not result in easy determinatiopn of the related 'private key' the 'public key' can be made available to all. This means, for example, that anyone can have access to 'public keys', which can be used to authenticate information, without fear that they will be able to create information which will pass the authentication tests.

For example, a check issuer can encrypt payment instructions with its 'private key', which is known only to the check issuer, and make its 'public key' available to all check payers without fear that its 'private key' will be compromised. Then, anyone with access to the check issuer's 'public key' can decrypt any encrypted payment instructions created with the 'private key' and authenticate or verify the payment instructions.

A 'public key' system can also be used to authenticate identification cards, packages or containers, people (for example, 'Biometrics'), and any other type of information.

Authentication

'Public key' cryptosystems can be used to authenticate information the same way that 'shared secret key' cryptosystems can be used to authenticate information. The major difference is that, instead of using a 'shared secret key' for encryption and decryption, a 'private key' is used for encryption and a 'public key' is used for decryption.

Here is an example. The dollar amount along with the check, bank account and bank numbers printed on a bank check would be entered into an encryption algorithm. Using the check issuer's 'private key' encrypted payment instructions would be calculated.

The encrypted payment instructions would be printed on the check. However, because 'public key' cryptosystems require a large number of characters to represent encrypted information, this information would be printed on the check in a machine readable form such as a 2D barcode. Then any check payer with a barcode reader and access to the check issuer's 'public key' could authenticate the payment instructions.

The check payer would use the 'public key' to decrypt the encrypted payment instructions printed on the check. The necessary mathematical calculations and comparisons of the actual and expected information would then be undertaken. If the decrypted payment instructions were not equal to the expected information, then it would be assumed that the check was an alteration or counterfeit.

If in this example the payment instructions had been hashed before they were encrypted with the 'private key' then this example would have shown a digital signature system.

Digital Signatures

A 'digital signature' can be created with a 'public key' cryptosystem like RSA and DSA. Instead of encrypting the dollar amount along with the check, bank account and bank numbers printed on a bank check as discussed above, a hash function would be used to compute a message digest of this bank check information. The check issuer's 'private key' would then be used to encrypt the message digest and this output would be called a 'digital signature'. See Ethent Views: " Hash Function Authentication" for a discussion of hash functions.

Here is one example of how a 'digital signature' system can be used to authenticate information - the dollar amount printed on a bank check:

A hash function is used to produce a message digest from a bank check's dollar amount. A 'private key' is used to encrypt the message digest. This output is called a 'digital signature'. An authenticator decrypts the 'digital signature' with the 'public key' and the output should be the message digest that had been produced from the bank check's dollar amount by the hash function. The authenticator then uses the hash function to generate a message digest from the bank check's dollar amount. The two computed message digests are then compared and if equal the bank check's dollar amount has been authenticated.

Ethent Views

2) For greater security a hash function should be used before encryption with the 'private key'.