Signing applications must have access to a PRIVATE KEY. RedTitan uses the Windows infrastructure to protect private keys. A test certificate may be created using the Windows MAKECERT utility, but in commercial applications, a signing certificate is normally purchased from a Certificate Authority. The CA will validate the purchaser credentials and issue a time limited certificate for the named purchaser with a private and public key. This information is held in the Windows Certificate Store and protected by the user login password.

(Note: EscapeE requires access to at least one private key certificate profile defined using the EECERTS Certificate management utility)

Encryption operations only require access to a PUBLIC KEY (or a number of public keys). This public key information may be held in a named certificate store or externally in disk files. You (the originator) must first obtain (once) a public key for this purpose from each of the intended recipients; this process is called a key request. Each recipient must supply a X.509 or a PKCS #7 format public key file. This can be created by exporting (on the recipient computer) a certificate from the Windows store, or using similar services on MAC, LINUX or other platforms. There are no security requirements and the ( .CER, P7B or P7C format) file can be sent by email to the originator. The recipient, however, is assumed to only respond with a certificate where access to the private key has been securely retained.

RedTitan EscapeE will decrypt content automatically from the information supplied in the encrypted PDF. No special provisioning is required. If you are not an intended recipient for the PDF (i.e. the correct private key cannot be located in the Windows Store) then EscapeE will display the serial number of the appropriate private key certificate and the name of the issuing authority. If you have no access to the private key only the plaintext certificate identification information in the PDF encryption wrapper is available - the PDF text and images cannot be displayed and remain protected by the encryption applied by the originator.

A certificate is uniquely identified by a common name (CN), a serial number and the issuing authority.

 e.g. CN=RedTitan Ltd, CA=Thawte Code Signing CA – G2, SN=30 E6 14 B1 8A A3 0A 9D 22 5A ED C8 E0 1E 15 0A 

Complex certificate specifications of this form are replaced in the RedTitan EscapeE interface by using a short alphanumeric name called a profile. A database of profile names is maintained by the program RedTitan EECERTS. The unique profile name is used instead of a complete certificate specification. A group of profiles and certificate disk file names can also be defined as a list, simplifying the process of creating a recipient list.

To allow signing in EscapeE, the user must define at least one profile using EECERTS where the specified certificate has an associated private key. If the Windows defaults have been used when importing certificates, then the appropriate private key certificates are located in the My store. Note: Internet Explorer calls the "My" certificate store "Personal".

The integrity of an individual certificate can be tested because its contents are itself signed with a private key. A test certificate may be self signed but normally a Certificate Authority (CA) will issue user certificates signed by the CA itself or an intermediate CA. Windows is pre-installed with a number of certificates that can be trusted and these are typically located in the Trusted Root Authorities Certificate store. EscapeE will give a trusted status to PDF to that are signed by a certificate ultimately linked to a trusted root certificate. By default, Adobe Reader will only trust certificates that chain to a CA on the Adobe Approved Trust List (AATL), were signed when the certificate was in date, and have not been revoked. A large enterprise like a government body may act as its own certificate authority but end users buying a signing certificate for PDF operations can simplify housekeeping by selecting a vendor from AATL.

If a private key is lost or compromised then its trust status can be refuted by posting the certificate name on a certificate revocation list (CRL). To completely validate a PDF trust status the CRL must be checked - this typically requires access to the Internet. Large enterprise also impose other restrictions on how a certificate may be used (Intended use).

PKCS relies primarily on the properties of a matched pair of very large prime numbers. Conventionally one of the numbers is held securely as the private key and the other number is distributed freely as a public key.

Using a cryptography technique defined by Ron Rivest, Adi Shamir and Leonard Adleman (RSA), data encrypted with a private key can only be decrypted by the matching public key and vice verse. The RSA algorithm is intrinsically a slow process and, in practical applications, techniques are used to restrict the size of data that has to be processed.

In a signing application only a digest of the PDF contents are processed by RSA. A digest is produced by processing the serialised contents of the PDF with a hashing function to produce a fingerprint of a small fixed size (128 bits). PKCS supports a variety of hashing functions including SHA1 and MD5. These functions are designed to minimise the possibility of a file with different contents having the same digest.

The contents of a certificate encrypted PDF are secured using a fast symmetric data cryptography technique based on an internal password key. The internal password is in turn protected using RSA encryption using the public keys from a series of digital certificate provided by each of the intended recipients. An individual recipient can derive the internal key by applying the appropriate private key and thus decode the document contents. The internal key is never published and is randomly created during the PDF encryption process.