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. 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. Digital signature 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, 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. Sign requirements and security policies 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. 72  IBM AIX Enhancements and Modernization