Formatta products incorporate several cryptographic techniques in order to exchange information in a safe and secure environment. The form author has access to a wide selection of powerful algorithms and configuration options, including symmetric and asymmetric (public key) encryption, safe hashing, digital certificates and digital signatures support, and the possibility to define multiple sets of data which can be independently protected.
The sections below summarize Cryptography in general, and Formatta's cryptographic techniques in particular.
A good method to ensure a block of data is authentic (the contents didn't change as a result of transport and storage errors, unauthorized intervention, etc.) is to create a short "digest" of the data. Because the way in which this digest is calculated is predictable and reproducible, simply recalculating the digest from the data and comparing it to a previously calculated digest can verify the authenticity of the data. If these digests are identical, then we can affirm the entire block of data is authentic, with a very high degree of confidence. Algorithms for creating digests (also named hashing algorithms) must provide at least two basic features: be one-way (the original data is hard to be reconstructed from the digest) and collision free (it will be extremely unlikely to find another non-identical block of data which will have the same digest).
Other common names for the hashes are message digest, (digital) fingerprint, and thumbprint.
Examples of popular hashing algorithms are SHA1 and MD5.
Encryption algorithms (or ciphers) provide means to transport and store data in a secure manner, using an unsecured medium. Secure means that only the intended recipient should be able to reconstruct the original data from the encrypted data, all other parties that have access to the unsecured medium being unable to do so. This involves a secret, usually a key, which must be known by the recipient.
The symmetric encryption algorithms use the same key to encrypt and decrypt the data, so both the sender and the recipient must know it. The key is usually short compared to the data and must be transmitted or stored using a secure medium. The advantage lies in providing a secure medium for the key transmission or storage, rather than for the whole block of data.
There are many kinds of symmetric ciphers, designed to fit specific purposes and situations. The strength of such a cipher is given by a multitude of factors, one of them being the key size.
Examples of symmetric ciphers: RC2, RC4, DES, 3DES, Blowfish, AES.
Public key ciphers are a subset of the class of asymmetric encryption algorithms, where the keys used for encryption and decryption are different. They have a special mathematical relationship to one another, but this relationship is specifically designed so it would be very hard to find one key given only the other key in the pair. This interesting feature eliminates the need of the secure channel for key transport: the recipient can provide one of the keys to the sender in an unsecured manner, and the sender will use it to encrypt the data. Because the other key is needed to decrypt it, no one but the recipient will be able to decrypt the data, not even the sender.
The key that is provided to the sender is the "public key", while the one which stays with the recipient is the "private key". The public key can be sent or stored using an unsecured medium, and often it is even published in "public key repositories". However, the corresponding private key must be protected by the recipient (holder of the private key), otherwise the system is compromised.
Another interesting feature of some public key ciphers is the ability of the holder of the private key to use it to encrypt the data. Because this data can be decrypted using the public key, it is not secure, but since only that public key can be used to decrypt the data this provides a mechanism of authenticating the sender's identity, so it can be used for implementing "digital signatures".
Because public key algorithms are generally slower than symmetric key ones, they can be used for "key exchange", providing the secure medium for transmission of the key used by a symmetric cipher. For the same reason, when a block of data is authenticated (signed), usually it is not the whole block of data which is encrypted using the private key, but only the digest.
Examples of public key algorithms include: RSA, Diffie-Hellman.
The types of ciphers presented above permit the protection of data from unauthorized viewing or use, whether stored or transmitted using an unsecured medium. In addition, a digital signature permits the authentication of the sender and evidence the associated data was not altered.
Public key algorithms permit this: when data is encrypted with the private key, anyone having access to the public key may verify the data and the sender. As discussed above, usually the data is hashed, and then the hash is encrypted with the private key. To verify a signature, the recipient hashes the received data with the same hash algorithm, decrypts the received encrypted hash, and compares the two hash values. If they are identical, then he has successfully authenticated the signature (as well as the integrity of the data itself).
There are many applications for digital signatures. Obviously, they can be used to sign documents, but virtually any kind of data can be signed: date and time values, identity information, random challenge phrases (e.g., passwords) to prove the identity of a computer or user, other signatures, and so on.
A digital certificate is a collection of data that describes the identity of an entity (person, computer, organization, etc.). It is issued by a Certificate Authority (CA), which digitally signs the certificate. Who can be a Certificate Authority? There are no restrictions, since a CA may be another person, computer, organization, etc. However, a common purpose of all CAs is to be trusted by the parties using the certificates that the information contained in the issued certificates is accurate.
A certificate usually contains information related to the subject entity (names, addresses, the public key), information about the issuer and the certificate itself (time validity, serial number, certificate hash, issuer's signature, methods to access issuer's statement, revocation information), description of the algorithms and purposes for which the certificate is considered trusted.
Digital certificates can be an efficient and convenient way to prove identity. This works based on trust delegation: you trust that a given digital certificate is valid because you trust the Certificate Authority that issued the digital certificate.
So you can use the public key on the certificate to authenticate digital signatures originating from that entity and/or create a secure medium to transmit the data to that entity.
Also, if for some reason the subject's private key was compromised or the information in the certificate is no longer valid, a CA can revoke the certificate and provide means to verify the revocation status to potential users of the certificate.
The most important things to keep in mind when dealing with cryptography is to ensure that the secrets that permit only the authorized persons to decrypt or sign a block of data are indeed secret. If an unauthorized individual or organization knows the password or the private key, then the entire system is compromised.
The first rule is, don't tell anyone your password - there is hardly a valid reason to do so. Formatta products permit the form authors and users to have individual, unshared passwords. A second rule is, choose password which is hard to guess, or better - choose a string of words or 'pass phrase'. A common mistake is to use a common word, the name of someone in your family, or something equally easy to guess, as your password. Such passwords are quickly compromised (discovered) by even casual and novice hackers.
When using digital certificates, your most precious asset is your private key. Under normal circumstances, it will never leave your computer - not even when the certificate is issued. If you aren't the only person who has access to your computer, it is a wise thing to enable strong protection for your private key - you can do this when you request the certificate or when you install it from a file. The digital certificate itself is public and you can export it to a file to give it to others, but pay attention to not include the private key when exporting, because this procedure is reserved for backup purposes - keep that file in a safe place.
Almost all hashing in the Formatta product suite is based on the SHA1 (160-bit) algorithm, and is internal to the Formatta products (that is, it is not used in any security interface outside of the Formatta products). The exception is the signing process, which uses CryptoAPI's implementation of SHA1.
One of the encryption methods is Formatta Encryption, which uses Diffie-Hellman 512-bit key exchange to encrypt a 128-bit random key. This key is then used by a BlowfishSK symmetric block cipher to encrypt the actual data. The Diffie-Hellman coefficients are calculated from two independent passwords. The effect is that either password is equally capable of decrypting the data. One of the passwords is reserved for the form author and is set up when a form is password-protected or 'locked'. The user who fills in the form can supply the other password.
No passwords or password hashes are stored with the form. Only the Diffie-Hellman public values are stored.
The algorithms are implemented by the Formatta applications.
The key exchange mechanism defined by the digital certificate is used to encrypt a random key, which in turn is used to encrypt the data with the RC2 symmetric block cipher. When encrypting, the public keys embedded in the certificates of the form author, current user, and optionally a third entity encrypt the symmetric key. This allows anyone of these entities to decrypt the data.
All certificates involved are stored with the form in standard ASN.1 encoding, but not the private keys. In fact, Formatta applications never access the private keys directly. Whenever a form is used, the embedded certificates are compared with the certificates installed on the user's system, and the user is given the possibility to install new certificates is a simple way.
Formatta can handle X.509 v3 certificates, and it uses the Windows CryptoAPI library.
Formatta forms contain multiple encryptable objects, which can be individually signed or encrypted. This flexibility allows authoring complex forms with elaborate security scenarios, where the form layout can be authenticated and protected, multiple users can sign and encrypt parts of the form, the form can be securely routed among the users, and automated decryption and data extraction services can be provided by Formatta Server. All this is possible with a single form, and the users never need to exchange passwords or other security keys.
A form can contain these objects:
The Form Layout Hash - There is only one object of this kind in the form, and it is generated when a form is saved to the disk from within the Formatta Designer product. When a form is locked, this object can be signed and will be encrypted using the encryption method chosen by the form author. The users cannot change this.
Field Sets - Each form can contain one or more Field Sets. A Field Set can be set up to allow/not allow encryption and/or signing.
Form Attachments - The files attached to a form are aggregated in this object. This Object can be set up to allow encryption and signing.
A digital signature in Formatta applications is implemented using the digital certificates infrastructure. A set of data is packed into a single memory block, which is passed to CryptoAPI for signing. The process then consists on hashing the block and encrypting the hash with the certificate's private key.
The signing and signature verification are performed on unencrypted data, so if the data is encrypted, it must be decrypted first.
The form's author has the option to sign the form layout when locking the form. It is strongly recommended to use this option, as this provides the best way for him or for the users to detect form layout tampering, so a potential attacker cannot deceive users into filing an unauthorized form.
In addition to the form layout, which is to be considered fixed after the form is locked and distributed, individual users filing the form can sign the data entered in the form. To enable this, the form author must organize the fields into one or more Field Sets, and set the signing preferences for each Field Set, like if the Field Set supports user signatures, if the users are allowed to "un-sign" the Field Set, and the maximum number of signatures which can be applied to that Field Set. In addition to this, the author must provide a method for the user to perform the signing operation, either by placing an action button or a hyperlink with a command in the form.
If the form was designed to accept file attachments, the Attachments object can be configured in the same way as a Field Set in respect to the encryption and signatures.
A signature can be inspected at any time using Filler. The person verifying a signature can check if the signing certificate is valid (the certificate is not expired, it resolves correctly to a certification path ending in a trusted root certificate, and it was not revoked) and that the signature matches the signed data.
The signature for the form layout is placed on the Summary Info window, and for the Field Sets and Attachments there is a button on the toolbar that provide access to their signatures. The signatures for a signed Field Set can be also inspected by right-clicking on any field contained in the Field Set and selecting the signer's name.