The mathematical underpinnings of cryptography and the techniques used to build useful systems are interesting in their own right. However, cryptosystems are generally used as part of an overall security policy and, as Bruce Schneier of Counterpane Security remarks, "Security is a process, not a product." Further, security is about managing risk, not eliminating it and it's always necessary to balance costs against benefits. These might be monetary, as in the case where it makes little sense to spend $10,000 to protect something worth $1,000, but there may also be many less tangible costs and benefits to be considered. It's necessary to take into account how people actually use systems; what might seem a suitable solution from a technical perspective may in reality be flawed because people can find ways around its inconvenient elements. Further, there may be legal obligations, such as the need to ensure that data about individuals is secured against unwarranted third-party access, something that encryption can facilitate.
Many of these matters are beyond the scope of this series of articles, although this last feature will touch on some such issues. In particular, it will consider some areas where systems can be attacked, through cryptanalysis or in other ways, and will look at issues around key management, digital certificates, and digital timestamping.
Ciphers are generally based on mathematical problems that are difficult to solve, given the present state of knowledge. This caveat is important. For example, factoring large primes is extremely difficult and the practical consequence of this difficulty is that it may take hundreds or thousands of years on average, even using huge amounts of computing power, to identify the relevant primes in a public key and so calculate the corresponding private key. Hence, at present, plain text encrypted using, say, RSA with keys of adequate length can be considered absolutely secure for all practical purposes. That this might happen is certainly possible, although unlikely, and so it makes sense to continue using ciphers that have been well-evaluated and well-tested, and are considered secure.
A more important issue is whether a particular algorithm has weaknesses, whether in the form of sets of keys, which are relatively easy to break, or when used in particular circumstances, or when, as mentioned earlier, some ancillary routines, such as a pseudo-random number generator (PRNG), have flaws that introduce vulnerabilities. This is why peer review is essential and why various forms of cryptanalysis should be applied in attempts to defeat the encryption. Algorithms and implementations, which are examined in minute detail over long periods of time and which, having remained secure in a wide rang of circumstances, are increasingly likely to be reliable.
An example of what can happen is given by a recent incident reported by BugTraq and involving CyberPatrol, the censoring program formerly owned by Mattel and now by SurfControl. Why anyone would ever want to register the program is one of life's unfathomable mysteries, but anyone seeking to do so might be disturbed to learn that, as BugTraq pointed out, CyberPatrol's site didn't use SSL, but sent all details other than the credit card number -- including the expiration date -- in plain text. It did encrypt the number, although what it used was a substitution cipher which, as the alert remarks, was "equivalent to that ... found in the games pages of newspapers," and which anyone using pad and pencil could almost certainly crack. Nor is this an isolated incident. Regrettably, numerous software vendors are so lacking in competence, so focused on short-term financial gain, so contemptuous of their customers, so frantic to get aboard the latest gravy train, that they develop shoddy products with risible protection of private data and threaten with lawsuits those showing up their negligence.
Exhaustive search, the technique of trying all possible key combinations until one is found that fits, can be a practical solution in many cases, particularly if the range of possibilities to be searched can be reduced. SIM cards and PDAs, such as the various Pocket PC or Palm devices, are typically capable of being secured by a four-digit pass code with a requirement that exactly four digits be entered. Although this might seem equivalent to a 32-bit key offering 232 (4,294,967,296) possibilities, and therefore may appear to be moderately secure, in reality the number of possibilities offered is the same as a four-wheel combination lock of 10 places, 10,000, or only a little more than 213 . While this doesn't matter greatly so far as PDAs or phones themselves are concerned, the real problem comes when PDAs are used to make a connection into an otherwise secure network; a brute-force attack on 10,000 possible keys, which would entail trying half the possibilities on average, should succeed in a very few seconds.
With symmetric block ciphers, possible attack mechanisms include differential and linear cryptanalysis, algebraic attacks, and the exploitation of weak keys. The latter two depend on identifying particular symmetries. DES has four weak keys such that when plain text is encrypted using such a key and then encrypted a second time, the original plain text is recovered. IDEA, as mentioned earlier, has many more weak keys, but in each case it's important to ensure that these known keys are excluded. The major form of attack against hash functions is the birthday attack, described earlier -- a particular kind of brute force attack. Note, as mentioned, that a successful birthday attack on a hash function does not reveal the key.
More generally, if cipher text can be analyzed to show regularities or if a sample of plain text can be compared with the cipher text derived from it -- and, particularly in the case of stream ciphers, if a dynamic analysis can be carried out comparing the results obtained by differentially encrypting small parts of the keystream and comparing these with the actual results using the cipher -- then the odds against finding the key can be greatly reduced.
Eavesdropping and other attacks
Breaking a standard cipher with a good key is generally extremely difficult. Hence a more fruitful line of attack is to view the plain text in some way, or to bypass the cryptographic security. Earlier, I mentioned the many locations where e-mail is completely open to anyone with suitable tools to read. Trojans and program such as Back Orifice allow remote users to readily gain information from particular systems. Bugs exist and can be exploited. Ralph Senderek's recent paper claims that the Additional Decryption Keys (ADKs) added to the newer versions of PGP contained flaws in their implementation that made it trivially easy in certain circumstances to get at plain text.
Just as faxes appear in plain text, e-mails and other documents also need to be in plain text to be read on monitors. Monitors emit electromagnetic radiation and in some cases it's claimed that this radiation can be intercepted and copied to another display. The US government has developed certain shielding standards identified with the code TEMPEST (but now known as EMSEC -- Emission Security) that are claimed to provide protection. Ross Anderson at Cambridge University recently announced a software protection against intercepting such emissions.
Sniffers can be employed on local or wide area networks, and generally anyone with physical access to a network could investigate another system or intercept data that is traveling around. Files that are deleted are usually not overwritten for some time, "deletion" being simply a freeing of disc blocks by marking appropriately the relevant entry in the directory table. Windows uses virtual memory, meaning that transient data in RAM, including plain text for reading, will periodically be copied to the swapfile on disc and can be viewed by anyone with access to that drive. Files created using Word, Lotus Notes, Excel, and the like may be protected by inbuilt password systems, but these are so weak that protection can typically be broken in seconds using programs that are inexpensive and widely available.
Key management and related issues
It's sometimes useful to share keys locally. A key may be very valuable in that if it's lost, a large number of files become inaccessible. Of course this can be handled by storing a number of backup copies of the key, but it's better to minimize these, given the increased risk of illegitimate access. In other cases, as with the traditional bank vault situation, it may be prudent to arrange matters so that a minimum number of authorized users need to agree to use a key before it can have any effect.
Note that secret sharing mechanisms involve more than simply cutting a given key into bits and distributing it among different holders. In such a case, the absence of one person would mean the key couldn't be used. Rather, secret sharing schemes are designed to allow selected numbers of shares and selected numbers of required users while maintaining security. For example, a key might be divided among five holders such that any three could act together. Two widely-used schemes are Shamir's scheme, which is based on polynomial interpolation, and Blakley's scheme, which is geometric in nature. There's also a visual form, developed by Naor and Shamir, where the individual elements are presented as transparencies and shared appropriately among the holders. These transparencies can take the form of perfectly innocent-looking pictures.
Zero knowledge proofs and special signature schemes
When someone witnesses a signature, it's normally easy to conceal the contents of the document. Similarly, with electronic documents there may be occasions where it's appropriate to have someone sign without their learning the content. It could also be necessary on occasion for someone to prove he knows something without revealing any other information.
The second aspect can typically be handled through some form of challenge-response activity. One person is asked to do something that could only be done by someone who knows a relevant secret that can be verified. A trivial example often given is that of Ali Baba's cave. This consists of a corridor running round three sides of a rectangle, the fourth side being a common, open space where the challenger can stand. On the opposite side of the rectangle from this space, closing off the corridor at that point, is a door that can only be opened by speaking a magic phrase. The verifier checks that the door exists and is secure and then asks the other to appear from one or other corridor exit as he specifies and for as many times as he wants until he's confident that the person does actually know the magic phrase. Note that the verifier has received proof confirming that the other person knows the magic phrase but the verifier cannot prove this to anyone else.
Standard digital signatures have the property that anyone in possession of the relevant public key can verify -- without the signer's being present -- that the corresponding private key was used to sign the document. Such signature schemes are termed self-authenticating. However, what's known as an undeniable signature scheme requires that the signer attest to the validity of the signature. In order to avoid signers dishonestly denying that they signed something, undeniable signature schemes involve adding what's known as a disavowal component. Verification is then carried out using a challenge-response mechanism. Provided a reasonable key length is used, say 768 bits, the likelihood of a signer repudiating a document is miniscule.
A blind signature scheme is one that allows one person to have another sign a document without the first person revealing anything about the document to the signer. It's accomplished by introducing a random value that conceals the information exchanged. Blind signature schemes are relevant in a variety of areas including in timestamping and in cases where anonymity is relevant, for example where digital cash is concerned. It is currently an area of extensive research.
One risk with asymmetric cryptography is that a given public key might not be that of the person claimed. This problem is easy to overcome when everyone knows everyone else, but a considerable benefit of public key cryptography is that it can be used precisely in ad hoc groups where people don't know each other, and so some method is needed to authenticate the link between a person and his public key. This is currently handled by issuing digital certificates, which are effectively a form of credential.
Typically, a certificate will contain a public key and an associated name, an expiration date, and other relevant information. The certificate is, essentially, a digital signature from a trusted third party attesting to the authenticity of the public key and its association with the named individual or organization.
One widely-used format of certificate is defined by the X.509 standard, but other formats exist with that devised by PGP being very widely used. The PGP format includes the PGP version number used to create the key associated with the certificate, the holder's public key and other identifying information (which might include a photograph), the validity period of the certificate, a note of the preferred symmetric encryption algorithm (that is, CAST, IDEA, or Triple-DES at present), and the digital signature of the certificate owner (that is, a signature made using the private key element corresponding to the public key shown on the certificate). There may also be several other digital signatures, all attesting to the authenticity of the information offered, the assumption being that among these will be some that are recognized by a person who considers the certificate to be trustworthy.
This recognition of trust is an important element in certification. It might seem odd that the PGP certificate doesn't call on an impressive hierarchy of authentication but, in the end, the worth of any certificate is dependent on nothing more than trust at some level. Given the ease with which passports, birth certificates, and other traditional forms of identity can be forged, and given that the chances are slight that a particular civil servant at, say, a future Ministry of Personal Identity actually knows me personally, there might be considerable doubt as to the authenticity of a certificate from there compared with one from a linked circle at a much less grand level.
In reality, a chain of certificates may well need to be issued anyway. I may personally be known to my department head who will issue a certificate authenticating the key I supply. That will be attested to by a department signature, attested in turn by a company signature, that perhaps attested further by a professional or trade body signature, and perhaps even that in turn by some national organization of international repute, such as the post office.
It's clear that the higher up a chain one travels the more hinges on the integrity of the keys that support the digital signatures offered. Someone making a successful attack (perhaps by some form of theft or bribery rather than by cryptanalysis) on the keys held by a certificating authority at a high level could cause immense damage to the security of the documents dependent on those keys. If the keys themselves were revealed then the relevant documents would be compromised while if the certificate authority's keys were to become known, then false certificates could readily be issued although, of course, earlier certificates will remain valid.
From time to time certificates need to be revoked. This may happen when they expire, naturally, but it may also occur when keys have become compromised or when someone has left a particular job. Lists of such revoked keys are regularly issued and it's important to check that a certificate that has been offered has not been revoked.
A digital signature merely confirms that a particular private key was used to encrypt a document or, more probably, that document's message digest. A person might dishonestly try to repudiate a document by claiming that at the time the signature was made the key had been compromised. Alternatively, a person might sign a document although the relevant key had already been revoked. Given the ease with which any time whatever can be associated with a file there needs to be some other mechanism to tie such a signature to a particular moment in time. If the time that the signature was applied is known accurately, then a correct judgement can be made as to its validity.
Someone with a timestamped digital signature sends the message digest to a timestamping service, which then returns a timestamp certificate. Anyone who wants to verify the signing time then uses the certificate (along with an algorithm appropriate to and specified by the particular certificate) to verify that the time claimed is correct.
Cryptography is an important element in overall security, particularly with the expansion of international electronic activities. Further, ciphers have improved to the point that, with proper use and adequate key lengths, they are effectively unbreakable. This is important for users who need to ensure that, having encrypted something, they can later have access -- something that requires sensible management of the relevant keys. At the same time, revealing the keys to others means that encrypted documents might as well be in plain text, so it's essential to make sure that keys are secure. Private keys are long and unwieldy, hence they need to be stored on a hard disk or a removable disks of some sort, which, in turn, is protected by a further level of encryption with a suitable passphrase. It's at this level -- whether through the medium of users employing trivial passphrases, by having those phrases written down, sent in clear text over a network, displayed in clear text on a screen, left in caches or in virtual memory, revealed by support staff to a caller pretending to be the owner, or by one of the myriad errors that are commonly made -- that the weak link exists.
Murdoch Mactaggart is a freelance writer
and business consultant who writes on software development, the Internet, and on
business and management issues around these areas. Whether readers can make
accurate sense of what he writes is a moot point but, flexible though he tries
to be, he generally sticks to English rather than introducing languages of his
own making. Contact him at IBMDev@TextBiz.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
