See more on Chunks in general.
This is a Digital Signature, used to validate that the file’s or chunk’s contents have not been changed and were prepared by the specified sender.
Redo this! It should be as similar in structure to KHSH as it can be. It will be used as an authentication mechanism and tieing chunks together, too.
If the a (correlated) Flag is set, then the instance describes the extracted, restored file of that same DATA instance.
If the a (correlated) Flag is not set, then the instance describes one or more target chunks.
The a (correlated) Flag must be absent; if set see the description of SIGN-a instead.
The i (instance index) flag must be set if and only if the r (range) flag is set.
The r (range), p, and c flags is allowed as usual.
The y (payload specification) flag is allowed, but rarely useful because the digital signature won’t compress, and there is no need to encrypt it. However, it is allowed because advanced transforms may be useful. But using it is discouraged if it isn’t specifically set up to add value.
The b (subtype) flag must be set.
Subtype is set to 65 (hex 41).
The Payload contains a target chunk ID, Security Level Indicator, and a digital signature for the target chunk.
This is identical to the Chunk ID used by the TOCN chunk.
The “security level” is a uintV indicating how secure the signer is, as illustrated below. The values are spaced apart so that additional levels can be added, and keep them in order from least to most safe. However, by defining only a few distinct levels, there will be less confusion about just how to rate something.
A value of 16 indicates that the program automatically signed the data, without direct user involvement. Specifically, any automatic script or batch file running on the system (possibly without the user’s knowledge) would produce signed files with this level. This level of signing is not proof against a worm-type virus, as once the user is logged in, any background software can produce signed archives.
A value of 32 indicates that the user must interact with the system to produce a signature. That might just be a dialog box that says, “OK to sign using default signature?”.
A value of 48 indicates that the passphrase was actually supplied by the user in order to access the private key. A script cannot do that without user interaction.
A value of 64 means that the public key is stored on a removable media, such as a CD-R or a smart card, and is only presented to the machine when it is momentarily accessed.
So, what’s to prevent an email worm virus from changing a 16 to a 48? This number is stored inside the encrypted envelope, so that you cannot change a value without invalidating the signature.
While too heavy for script-type viruses, a Trojan Horse could include a full-blown ZIP2 creator program that’s been suitably modified to report the level wrong. So, the public keys themselves should be known to be secure to a particular level, offering a cross-check if necessary.
So if it can be defeated, why report the level at all? Because Windows 2000 has a “public key infrastructure” that seems to provide software running in a particular user’s account access to encrypt/decrypt ability without further prompting, once that user has logged on. If this is used to sign archives, there will be heavy use of level 16, which is useless against malicious scripts. This value was introduced to distinguish this kind of casual but useless signing from a stronger signature.
The digital signature algorithm is applied over the entire content of the target chunk, from the first byte of the size through the checksum inclusive.
Should the Level Indicator simply be hashed after the message in the previous paragraph, or combined with the hash during the signature computation?
The digital signature is computed using OpenPGP... ∴ Need to document details!
The a (correlated) Flag must be set; if absent see the description of SIGN instead.
The r (range of instances) , p (multi-part) & c, and y (payload specification) flags are all available. The i (instance sizes field is present) flag must be set if and only if the r flag is set.
Subtype is set to 65 (hex 41).
The Instance Number matches the Instance Number of the DATA it applies to, as with any a-flagged chunk type.
The Payload contains the Digital Signature Value for the data, as described above.
The digital signature is computed over the original contents of the DATA instance, before it is compressed and otherwise transformed and broken into one or more chunks. That is, check the signature on the file after extracting it.
Page content copyright 2003 by John M. Dlugosz. Home:http://www.dlugosz.com, email:mailto:email@example.com