12.3. Implementing a Signature ClassNow that we've seen how to use the Signature class, we'll look at how to implement our own class. The techniques we'll see here should be very familiar from our other examples of implementing an engine in the security provider architecture. In particular, since in 1.2 the Signature class extends its own SPI, we can implement a single class that extends the Signature class. To construct our subclass, we must use the following constructor:
Once we've constructed our engine object, we must implement the following methods in it:
In addition to those methods, there are a few protected instance variables that keep track of the state of the signature object--whether it has been initialized, whether it can be used to sign or to verify, and so on:
These variables are not normally used by the subclasses of Signature, since the logic to maintain them is already implemented in the Signature class itself. Here is an implementation of a signature class. Note that the XYZSign class depends on other aspects of the security architecture--in this example, the message digest engine to create an SHA message digest, and the DSA key interfaces to handle the public and private keys. This is very typical of signature algorithms--even to the point where the default name of the algorithm reflects the underlying components. The actual encryption of the message digest will use a simple XOR-based algorithm (so that we can, as usual, avoid the mathematics involved with a secure example). Class Definitionpublic class XYZSign extends Signature implements Cloneable { private DSAPublicKey pub; private DSAPrivateKey priv; private MessageDigest md; public XYZSign() throws NoSuchAlgorithmException { super("XYZSign"); md = MessageDigest.getInstance("SHA"); } public void engineInitVerify(PublicKey publicKey) throws InvalidKeyException { try { pub = (DSAPublicKey) publicKey; } catch (ClassCastException cce) { throw new InvalidKeyException("Wrong public key type"); } } public void engineInitSign(PrivateKey privateKey) throws InvalidKeyException { try { priv = (DSAPrivateKey) privateKey; } catch (ClassCastException cce) { throw new InvalidKeyException("Wrong private key type"); } } public void engineUpdate(byte b) throws SignatureException { try { md.update(b); } catch (NullPointerException npe) { throw new SignatureException("No SHA digest found"); } } public void engineUpdate(byte b[], int offset, int length) throws SignatureException { try { md.update(b, offset, length); } catch (NullPointerException npe) { throw new SignatureException("No SHA digest found"); } } public byte[] engineSign() throws SignatureException { byte b[] = null; try { b = md.digest(); } catch (NullPointerException npe) { throw new SignatureException("No SHA digest found"); } return crypt(b, priv); } public boolean engineVerify(byte[] sigBytes) throws SignatureException { byte b[] = null; try { b = md.digest(); } catch (NullPointerException npe) { throw new SignatureException("No SHA digest found"); } byte sig[] = crypt(sigBytes, pub); return MessageDigest.isEqual(sig, b); } public void engineSetParameter(String param, Object value) { throw new InvalidParameterException("No parameters"); } public void engineSetParameter(AlgorithmParameterSpec aps) { throw new InvalidParameterException("No parameters"); } public Object engineGetParameter(String param) { throw new InvalidParameterException("No parameters"); } public void engineReset() { } private byte[] crypt(byte s[], DSAKey key) { DSAParams p = key.getParams(); int rotValue = p.getP().intValue(); byte d[] = rot(s, (byte) rotValue); return d; } private byte[] rot(byte in[], byte rotValue) { byte out[] = new byte[in.length]; for (int i = 0; i < in.length; i++) { out[i] = (byte) (in[i] ^ rotValue); } return out; } } Like all implementations of engines in the security architecture, this class must have a constructor that takes no arguments, but it must call its superclass with its name. The constructor also is responsible for creating the instance of the underlying message digest using whatever algorithm this class feels is important. It is interesting to note that this requires the constructor to specify that it can throw a NoSuchAlgorithmException (in case the SHA algorithm can't be found). The keys for this test algorithm are required to be DSA public and private keys. In general, the correspondence between an algorithm and the type of key it requires is very strong, so this is a typical usage. Hence, the two engine initialization methods cast the key to make sure that the key has the correct format. The engine initialization methods are not required to keep track of the state of the signature object--that is, whether the object has been initialized for signing or for verifying. That logic, since it is common to all signature objects, is present in the generic initialization methods of the Signature class itself. The methods that update the engine can simply pass their data to the message digest, since the message digest is responsible for providing the fingerprint of the data that this object is going to sign or verify. Hence, the only interesting logic in this class is that employed by the signing and verification methods. Each method uses the message digest to create the digital fingerprint of the data. Then, to sign the data, the digest must be encrypted or otherwise operated upon with the previously defined private key--this produces a unique digest that could only have been produced by the given data and the given private key. Conversely, to verify the data, the digest must be decrypted or otherwise operated upon with the previously defined public key; the resulting digest can then be compared to the expected digest to test for verification. Clearly, the security of this algorithm depends on a strong implementation of the signing operations. Our example here does not meet that definition--we're simply XORing every byte of the digest with a byte obtained from the parameters used to generate the keys. This XOR-encryption provides a good example, since it's both simple and symmetric; a real digital signature implementation is much more complex. These engine signing and verification methods are also responsible for setting the internal state of the engine back to an initialization state, so that the same object can be used to sign or verify multiple signatures. In this case, no other work needs to be done for that; the message digest object itself is already reset once it creates its digest, and there is no other internal state inside the algorithm that needs to be reset. But if there were another state, it would need to be reset in those methods. Copyright © 2001 O'Reilly & Associates. All rights reserved. |
|