In root key validation, a user verifies that a certain locally stored root key was issued by the corresponding certificate authority (CA). Since the user does not trust data downloaded from the network, the reference key fingerprint needs to be passed over another channel, for example printed in a widely available newspaper. Since the reference fingerprint is not in a digital format, the user needs to perform the comparison with the local root key fingerprint manually. This is where security problems due to human factors appear.
We demonstrate our concerns with a brief scenario. A user has just downloaded Netscape Navigator,
which comes with a series of top-level root keys. Unfortunately, Netscape has a misleading
``verify'' button in the window displaying the list of root keys, because ``verify'' only checks the
integrity of the certificate and the dates. Netscape has no way of asserting that the shown key
really is the one corresponding to that particular CA. The only way to verify the key reliably is to
obtain the key fingerprint through another channel than the Internet, for example from a newspaper.
When we select the ``edit'' button in the root key window, we see the following information for the
``Verisign Class 1 Primary CA key'':
Serial #:
32:50:33:CF:50:D1:56:F3:5C:81:AD:65:5C:4F:C8:25,
Fingerprint:
51:86:E8:4E:46:D7:B5:4E:29:D2:35:F4:41:89:5F:20. We call this fingerprint . In the
New York Times, we might find the following fingerprint for the same
key:
Fingerprint: 0x5186e81fbcb1c371b51810db5fdcf620. We refer to this fingerprint
as . A security-conscious user would go through the trouble of validating all 36 root keys that
came with Netscape by comparing all the reference fingerprints to the local fingerprints, while many
users will most likely not perform all the necessary checks, or only compare the initial or final
digits. To compute a public key which will match the 8 initial hexadecimal digits of the
fingerprint, it only takes trials on average, which is feasible on today's
computers. Other users might not understand the importance of verifying the authenticity of the
locally stored root key and avoid the validation. Hence, these human limitations greatly degrade
the security of the systems. We propose to use Hash Visualization to generate a visual
fingerprint from the binary fingerprint. When using Random Artto generate the visual
fingerprints of the two fingerprints and listed above, we get the images shown in
figure 4.
The visual fingerprints generated by Random Artare clearly easier to compare than the hexadecimal representation. Another advantage of this system is that people can remember structured images and recognize them later. Therefore, the user can possibly remember the image representing the fingerprint and perform the validation later. For example, Verisign could display their reference visual fingerprints in an advertisement on TV. At a later point in time, users can display the visual fingerprint on their trusted system and check whether they can recognize the image. Another application of the same idea is the validation of data or software downloaded from the Internet. The scenario is that a business traveler uses the computer that comes with his hotel room to read e-mail. The e-mail program could be a Java applet, downloaded from the Internet, such as the Pachyderm mail reader [14]. The user trusts the hotel computer, but how can he or she know that the Pachyderm applet is correct (i.e. does not contain a Trojan horse)? The obvious solution would be to display a checksum of the Pachyderm applet, which the user could compare with one written down on paper. But again, generating a visual checksum with Random Art would be more user-friendly, efficient, and the user would not need to keep a paper with the checksum.
