A digital signature is a bit stream appended to a message which establishes for the receiver of the message the source and integrity of that message. While there are a number of digital signature schemes available for use, the scheme being evaluated in CTBT is the U.S. Government-standard Digital Signature Algorithm (DSA). In brief, the reasons for selecting the DSA include the following:

• The fact that the DSA is a government standard.
• The inability to use DSA for encryption.
• The speed of signature generation.

Figure 1 depicts how this algorithm works.

Figure 1. The Digital Signature Algorithm

In DSA, digital information that is to be "signed" by a sender is first "hashed" using the Secure Hash Algorithm to create a 160-bit "message digest". This digest can be thought of as a digital fingerprint that compactly and uniquely represents the digital information to be signed. This digest is then passed through an algorithm that computes a 320-bit digital signature using a combination of integers that includes the private key. The resulting "signature", which has the effect of mathematically binding the message digest to an element identified with the signer (i.e., the private key), is appended to the original digital information. The recipient of signed information recreates the message digest from the original digital information and then runs an algorithm using the digest, the signature, public key, and other public cryptographic parameters in order to "verify" that the signature could have been generated only by the private key associated with the public key. It should be noted that, as DSA is an "asymmetric algorithm", the recipient’s ability to verify a signature does not give the recipient the ability to forge a signature. This is useful in systems where non-repudiation (i.e., the ability to prove to a third party that a message did, in fact, come from a given signer) is important.

The use of the digital signature algorithm will not, by itself, guarantee the authenticity of data in the CTBT IMS. There are a number of implementation issues that need to be addressed if the digital signatures are to be trustworthy. In addition, there are several attacks on DSA that need to be addressed in the system security.

The first implementation issue to be faced is the trustworthiness of source data to which digital signatures will be applied. All that a digital signature does is assure that from the time that the data was signed until it was successfully verified, it has not be corrupted. This fact raises several issues.

First, there is the danger of the original digital data being altered in some way prior to the time that it is signed. The digital signature does nothing to solve this problem and, in a sense, can make the problem worse by "blessing" information that is invalid. Typical approaches to this problem are signing the data as near to its point of generation as possible (the goal here is to minimize the points of access available to an adversary or other source of signal interference) and using various mechanisms, such as exclusion regions and tamper indicators, to limit access to the unsigned data.

Given the location dependent aspects of IMS data processing, an important variation on this attack (first identified by NTPO) is the movement of a sensing device to some location other than the location at which it is supposed to be monitoring. While the sensor would, in fact, be operating correctly and would be sending out authenticated messages, the data would be corrupt in two senses. First, it would not reflect the signals that would be seen at its designated monitoring site. Second, the signals that were received would be incorrectly interpreted as being those seen at the designated site. NTPO’s approach to this problem is to bind accurate position locating information (e.g., Global Positioning System (GPS) data) into the data packet being signed by the authentication unit.

In the CTBT, this problem of signing corrupted data is not confined to sensors and stations. If the processes used to generate event bulletins are corrupted or if the event bulletins are directly altered prior to transmission from the IDC, then signing the bulletins assures nothing more than the fact that they were sent from the IDC and have not been corrupted in the course of transmission. This problem is equally valid for any of the other computer-generated data sets, such as subscriptions or waveform requests, that might be digitally signed in the IMS.

Second, if digital data is simply signed, then the resulting signed data packet is vulnerable to "replay attacks". In this scenario, an adversary collects message traffic that suits his needs and then, when the time is right, replays this collected traffic into the message stream. This kind of attack could be used in CTBT to replace signals containing event data with signals showing ambient readings and could also be used to do just the opposite – to create events when no such signals are being received by the sensors. The typical approach to this problem is to include some kind of non-repetitive marker in the set of data being signed such that replay is readily detected by the receiver. Time stamps and sequence numbers are commonly used, as is "chaining" of messages (a technique in which a secure hash of one data set is included in the subsequent data set during authentication).

In addition to corruption of data before it is signed and replay after it is signed, the IMS needs to contend with attacks on the keys used to sign and verify the data. In typical public key digital signature schemes, each signer of data is assigned a unique private key. A recipient’s ability to verify a signature is typically taken as proof that the digital data was signed by a given signer. The underlying assumption is that the private key used to sign the data has not been compromised (i.e., disclosed or otherwise made available to anyone other than the signer); therefore, one implementation question is how to protect the private key such that it cannot be compromised.

In addition to private key problems, there are issues regarding the handling of the public keys. The most significant problem is referred to as the "man-in-the-middle attack." In public key authentication schemes, it is not uncommon for the sender to generate his own private key / public key pair. The critical issue in this arrangement is how to distribute the public key to an intended recipient of messages. If an interloper controls the communication channel between the sender and the receiver, then, when the sender transmits his public key, the interloper can capture it and forward to the receiver the interloper’s own public key. When the sender transmits signed messages, the interloper simply discards the signature, recomputes his own using his own private key, and then forwards the message and the new signature on to the intended recipient. Since the receiver is using the interloper’s public key, the new signature verifies correctly and neither the sender or receiver are any the wiser. Clearly, the danger here is that the interloper could change the content of the original message at will as well as independently initiate transmission of false messages.

Under the CTBT, the danger here is clear. If authentication units located at IMS stations create their own key pairs and publish these over the same communication channels used for transmission of data, then any node between the station and the ultimate user of the data could execute this "man-in-the-middle" attack. NDCs could use this to control the content of data flowing through their centers. The IDC could use it to paint any picture it wanted to about global activities. To address this attack, a means of establishing the authenticity of a public key needs to be implemented.

The most common approach to establishing this authenticity is through the use of "certificates". A certificate is a collection of information that binds a given sender’s public key to other identifying information about the sender. The certificate is viewed as trustworthy by the receiver because it is signed by a third party (called a "certification authority" or "CA") who is trusted by the receiver. The certification authority’s public key can itself be bound into a certificate signed by a higher CA. For example, a receiver located in one government agency may want to verify data transmitted by a sender in another agency. When operating within his own agency, the receiver would simply used the public key from that agency’s CA to verify a certificate of a sender in that agency; however, in verifying a certificate for a sender in another agency, the receiver must go through multiple steps. First, the certificate for the CA in the sender’s agency is retrieved. The public key in this certificate will permit the sender’s certificate to be verified; but, before this can be done, the sender must retrieve the public key of the government’s CA. This CA is trusted by the receiver (since his own CA’s certificate is signed by this higher CA) and is the entity that signed the certificate of the CA at the sender’s agency.

This arrangement of CA’s is sometimes referred to as a "certification hierarchy". In this scheme, all trust ultimately resides in a single CA at the root of the hierarchy. This is the authority that every user in the tree implicitly trusts. Unfortunately, in the CTBT, there does not appear to be any one organizational entity that meets this qualification. This problem can be addressed in at least two different ways. In the first, a network of certification authorities can be established in lieu of the typical tree structure. In this flattened structure, trust is established between a group of peer CAs. In the second approach, the notion of what constitutes a certification authority can be altered. Rather than the CA being a single entity, it can be a confederation of entities who collaborate to perform the function of a single CA. This approach can be realized through techniques such as "secret sharing" and "function sharing" such that the signing of a certificate is achieved using signature "shares" contributed by each of the parties in the confederation.

A final issue in the use of the digital signature algorithm is the potential for creation of "subliminal channels". A subliminal channel is a means of conveying hidden information in what appears to be an open set of information. In DSA, the signature itself can be used for this purpose. Through the controlled use of one variable, the sender can leak information to a given receiver and, all the while, the signatures continue to verify correctly for the other receivers. An implementor of an authentication unit might use this mechanism to publish the private key stored in an operating authentication unit. As noted above, access to this key would permit the intended receiver to forge messages from that authentication unit. The best defense against this problem is to insist on inspectable implementations of the digital signature algorithm. Closed designs, such as NSA’s Fortezza card, do not offer this possibility.