A verifying entity (a user program) that has both the package under evaluation, and the corresponding collection of hashes, runs the same hashing algorithm on the package in the same way as the signer, and compares the results to the original stored hashes to see whether anything changed. Even a small modification in the code results in a different digest, which indicates tampering or corruption. However, this verification is only as reliable as the reliability of the stored hash. The digital signature ensures this reliability. 

## Digital signature 

A digital signature uses public key cryptography to ensure data integrity. Like a signature that is written with ink on paper, a digital signature can be used to identify and authenticate the signer. However, a digital signature is more difficult to forge, and goes one step further: It can ensure that the signed data has not been altered. This is somewhat like designing a paper check or money order in such a way that if someone alters the written amount of money, the check becomes visibly invalid. 

In the context of AIX package signing, the signing program creates the digital signature by encrypting the seal’s hashes with the signer’s private key. Because only the signer possesses the private key, only the signer may perform this encryption. It is this collection of encrypted hashes that the signer stores in the package envelope (or a catalog file) along with the matching certificate, which collectively represents the digital signature. 

To verify the signature, the verifying program computes the same set of hashes across the various blocks of packaged data. It then uses the signer’s public key, which is embedded in a certificate, to decrypt the encrypted hashes that came with the package, thus obtaining the original hash as computed by the signer. If the two hashes match, the data has not been modified since being signed by an author in possession of the signer’s private key. 

Usually, the digital certificate is signed by a trusted CA. If not, the verifier can be sure of the certificate’s stability from one release to another but not of its origin. In relation to AIX packaging, a CA is not required; instead, a self-signed certificate is generated that contains the private key that is used when signing AIX packages during asset creation (build). 

## Sign requirements and security policies 

Sign requirements, also referred to as security policies, are the set of established rules AIX is using to evaluate a package signature. The AIX system doing the evaluation decides what sign requirements to apply at evaluation time, depending on its goals. 

Sign requirements that are specified by the signer and included as part of the package signature process are known as internal requirements , which are available to the system verifying a package signature, but the system may choose to use them or not (that is, disallow during diskless initialization or INUCLIENTS). Because the seal covers the sign requirements, the internal requirements are also certain to be intact if the package signature is valid. 

The most important internal requirement is the DSC requirement. This rule tells an evaluating AIX system how to identify a particular package or image asset. Any two packages that have (and successfully verify against) the same DSC are considered to be the same package, which allows the AIX build process to publish a new release version of a package that is verifiable before the package installation. As an example, the DSC for AIX 7.2.2.0 would contain the same appropriate signatures for AIX package versions of AIX 7.2.0.0 previously included in the AIX 7.2 release. When a new version of the AIX package is published, if a new version of the bos.rte.install  package has the same DSC, the package can be verified before installation, even if the binary executable file is different than the currently installed (included) executable file. 

