Literature Review

Digital Signature

A digital signature is an electronic form of a signature that can be used to authenticate the identity of the sender of a message or the signer of a document, and also ensure that the original content of the message or document that has been sent is unchanged. Digital signatures are easily transportable and cannot be imitated by someone else. The ability to ensure that the original signed message arrived means that the sender cannot easily disclaim it later.

Generating Digital Signature

Let us consider that B wants to digitally sign a document “m”. To sign the document, B simply uses his

private key, Kb- , to compute Kb-(m). Then, he sends both plane message “m” and encrypted text Kb-

(m). The Kb-(m) is digital signature of B. The digital signature Kb-(m) meets our requirements of

being verifiable, non- forgeable and non-repudiable. When A get the document “m” and Kb-(m), he/she

can prove that B had been indeed signed the document and was only the person who could have

possibly signed the document. A takes B’s public key and applies to the digital signature, Kb-(m),

associated with the document “m” i.e. he/she computes Kb+( Kb-(m)) and finds m. if this computed

message is identical or exactly matched to obtained plane message, he/she can argue that B could have

signed the document . It can be argued due to following reasons:

Whoever signed the message must have used the private key, Kb-, in computing the signature Kb-(m),

such that Kb+ (Kb-(m)) = m and the only person who could have known the private key, Kb- , is B.If

the original document, m, is ever modified to some alternative form, m’, the signature that B created

for m will not be valid for m’, since Kb+ (Kb-(m)) does not equal to m’.

One concern with signing data by encryption, however, is that encryption and decryption are

computationally expensive. When digitally signing a really important document, say a merger between

two large multinational corporations, computational cost may not be important. However, many

network devices and processes (for example, e-mail user agents exchanging e-mail) routinely exchange

data that may not need to be encrypted. Similarly, official agreements also need not to be encrypted.

Nonetheless, they do want to ensure that: the sender of the data is as claimed, that is, the sender has

signed the data and this signature can be checked and the transmitted data has not been changed since

the sender created and signed the data.

Given the overheads of encryption and decryption, signing data via complete encryption/decryption can

be overkill. A more efficient approach, using message digests, can accomplish these two goals without

full message encryption.

A message digest (also known as hash value) is in many ways like a checksum. Message digest

algorithms take a message, m, of arbitrary length and compute a fixed- length “fingerprint” of the data

known as a message digest, H (m). For example, a person can be uniquely identified by his/ her finger

print. Similarly a document can be uniquely identified by the hash value. The message digest protects

the data in the sense that if m is changed to m’ (either maliciously or by accident) the H (m), computed

for the original data (and transmitted with that data), will not match the H (m’) computed over the

changed data, m’. Given these considerations, the three important properties of message digest to be

noted are:

1. It is computationally infeasible to find any two different messages x and y such that H(x) =H(y).

2. A small alteration in the original message would cause significant change in the message digest.

3. Retrieval of original message is not possible form the message digests.

While the message digest provide for data integrity, it also helps with signing the message m. the goal

here is that rather than having B digitally sign the entire message by computing Kb-(m), he should be

able to sign just the message by computing Kb-(H(m)). That is, having m and Kb-(H (m)) together

(note that m is not encrypted) should be “just as good as” having a signed complete message, Kb-(m).

This means that m and Kb-(H (m)) together should be non-forgeable, verifiable ad non-repundiable.

The commonly used hash functions to compute message digests are MD5, SHA-1, SHA-128, SHA-256

etc. MD5 take arbitrary length message and compute fixed length (128 bits) hash value and similarly

SHA-256 computes fixed length (256 bits) message digest or hash value.

Digital

Certificate

A Digital Signature Certificate authenticates your identity electronically. It also provides you with a high level of security for your online transactions by ensuring absolute privacy of the information exchanged using a Digital Signature Certificate. You can use certificates to encrypt information such that only the intended recipient can read it. You can digitally sign information to assure the recipient that it has not been changed in transit, and also verify your identity as the sender of the message.

A Digital Signature Certificate explicitly associates the identity of an individual/device with a pair of electronic keys - public and private keys - and this association is endorsed by the CA. The certificate contains information about a user's identity (for example, their name, pincode, country, email address, the date the certificate was issued and the name of the Certifying Authority that issued it). These keys complement each other in that one does not function in the absence of the other. They are used by browsers and servers to encrypt and decrypt information regarding the identity of the certificate user during information exchange processes. The private key is stored on the user's computer hard disk or on an external device such as a token. The user retains control of the private key; it can only be used with the issued password.The public key is disseminated with the encrypted information. The authentication process fails if either one of these keys in not available or do not match. This means that the encrypted data cannot be decrypted and therefore, is inaccessible to unauthorized parties.

Similar System

1. Eco-Sign2. DB-sign3. KGpg4. XCA5. CA (gnoMint X.509 CA Manager)

DBsign:

DBsign uses various cryptographic modules. DBsign can import and use PKCS12 ”software tokens”. Cryptographic Modules, Security and Cost Optimization .The security of a digital signature system is determined by several criteria. Of primary concern is the protection of private key material. The

security of a user’s digital signature is directly related to the methods used to protect the user’s private key and the private keys of the CAs in the certificate chain. Cryptographic modules are used to protect the private key and to perform all cryptographic operations. Software cryptographic modules are less expensive, but also less secure. Hardware tokens are much more secure, but can be more expensive. Hardware modules can also be much faster than software modules. The digital signature system must be able to use both software and hardware cryptographic tokens. Sensitive data, such as large dollar-value financial transactions, translates into higher risk and therefore a higher security requirement. DBsign utilizes cryptographic modules that can accommodate both low and high-risk transactions. DBsign supports Class 3 and Class 4 certificates (stored on smart cards, PC Cards or USB tokens). The digital signature system must be able to enforce the use of higher security cryptographic modules for higher risk transactions while allowing less expensive cryptographic modules to be used for lower risk transactions.

DBsign enforces this in two stages. A user is not able to sign a high-risk transaction (such as payment authorization) with a low security cryptographic module (such as a diskette). When the signature is verified, DBsign determines that a transaction was signed with a cryptographic module of the appropriate security level. The ability to use cryptographic modules of varying security levels and the ability to enforce a policy for their use is crucial to optimizing the security/cost tradeoff.

The digital signature system must provide an interface that allows the use of third-party security products.

Another important part of reducing cost and risk is vendor independence. DBsign supports the use of third-party cryptographic modules and/or toolkits. An interface to external products and modules allows the digital signature system to take advantage of the latest technological developments and provides a means of adaptation to a changing environment.

The Signing and Verifying Process Signing data and verifying signatures in a relational database environment introduces several security and interoperability concerns.

The digital signature system must provide a method for specifying which data to include in the data to be signed.

DBsign allows application designers to decide which data elements need to be protected and gives them the ability to exclude some data elements from inclusion in the data to be signed. By protecting only the data elements that need to be protected, performance is increased because less data flows across the network.

The digital signature system must provide a method for modifying the data to include in the data to be signed without violating the integrity of existing signatures. As new functionality is added to systems, the data requirements for the transactions in the system may change. Sometimes data elements that need to be protected by the digital signature are added to a system. DBsign allows the signature composition to change without compromising the integrity of existing transactions.

The digital signature system must protect against database object spoofing. In some popular RDBMS products such as Oracle, it is possible for a user to copy an application table (or stored procedure object) into the user’s private table space and have that table be used by an application. This allows the users to alter the information in that table and possibly commit fraud. DBsign provides a mechanism

to prevent such attacks.

The digital signature system must allow the representation of data elements to be specified.

When verifying a signature, the each data element must be in exactly the same format as when it was signed. For example, there are many ways to represent a date (1-Jan-1999, 01/01/99, etc.). The same is true of floating point data. For example, if an application computes sales tax on a high value transaction, the difference between “0.8” and “0.85” percent can be significant. DBsign allows the representation of these data types to be specified.

The format of data to be signed must be publicly available. The format of the data that is signed must be made publicly available so that other systems can reproduce the same data to be signed if necessary. This enables different applications to be inter operable with respect to the format of the data to be signed.

DBsign meets this requirement through the use of the Extensible Markup Language (XML).

The digital signature system must easily integrate into the application to enable signing and verifying automatically.

DBsign supports the integration of digital signatures and signature verifications into the application work-flow enabling signatures and signature verifications to occur at strategic steps during the work-flow. The user does not need to be given the option to “sign” or “not sign” or to “verify” or “not verify”.

If signature verification fails because data was changed, the digital signature system must be capable of identifying for the user which data element was changed.

In a database environment, mass data entry changes are often fixed by a DBA via a SQL script. Such changes may be valid, but may modify data that is protected by a digital signature. This will cause the verification of that signature to fail.

Unless the changes to the data can be identified, it is impossible to determine if the change was the result of an innocent correction, or if an attacker has attempted fraud.

DBsign enables user to view the data as it was signed and as it currently exists in the database.

The digital signature system must include a timestamp with the signed data to show when the signature was generated. This timestamp must be protected by the digital signature.

DBsign uses signature timestamps. Protecting the timestamp with the digital signature ensures that the timestamp cannot be altered.

The digital signature system must verify that the signer’s certificate was valid at the time of signing.

Every X.509 certificate includes a validity period. Signatures generated outside of the validity period of

the signer’s certificate should produce an error when verified.

DBsign compares the signature’s timestamp to the validity period of the signer’s certificate to make this determination.

The digital signature system must retrieve the current date and time from a central, trusted source such as the database server or a timestamp authority.

Reliance on the client side clock presents a security risk because it can be altered by an attacker to misrepresent the date and time of signing. The digital signature system must not use the client workstation’s internal clock for signature timestamps or certificate validity checks. DBsign retrieves the timestamp from the database server.

Upon signature verification, the digital signature system must verify that the signer’s certificate has not been modified or revoked. The certificate chain should be verified up to and including the root certificate.

To ensure that a user’s identity cannot be forged, all certificates are digitally signed by the issuing CA. Each CA certificate is signed by a higher level CA. The root CA signs its own certificate. The root certificate is the only certificate that is explicitly trusted. All other certificates are trusted if they were issued by a CA subordinate to the root. Each CA publishes a Certificate Revocation List (CRL) and/or provides an online certificate status mechanism. DBsign checks this CRL. If any certificate in the chain was revoked before the date of signing, the digital signature fails.

The digital signature system should protect its list of explicitly trusted root certificates and should only honor certificates from the trusted hierarchies defined by these roots.

It is possible that a user owns a certificate issued by a commercial CA service (e.g., Verisign) in addition to their organizations PKI certificate. Users should not be permitted to digitally sign documents with certificates from an untrusted hierarchy. Upon verification, DBsign does not honor a signer’s certificate if it is not from a trusted hierarchy. DBsign does not add a trusted root certificate to the list of trusted roots without prompting the user. The user must be authenticated (via a password or a proof of private key test) before adding a new root certificate to the list. The list of root certificates should initially include only trusted hierarchies.

Kgpg:

KGpg manages cryptographic keys for the GNU Privacy Guard, and can encrypt, decrypt, sign, and verify files. It features a simple editor for applying cryptography to the contents of the clipboard.

XCA - X Certificate and key management

XCA creates and manages Certificate authorities and helps the user to and manages keys, certificates and manage keys, certificate, certificate sign requests, certificate revocation lists etc.All data is saved in an encrypted, portable database, and can be exported in various standard formats. XCA is also available for Mac-OS X and Windows systems.For a good work flow, certificate of certificates av easy task.

This application is intended for creating and managing X.509 certificates, certificate requests, RSA, DSA ansd EC private keys, Smart cards and CRLs. Everything that is needed for a CA is implemented. All CAs can sign sub-CAs recursively. These certificate chains are shown clearly. For an easy company-wide use there are customiseable templates that can be used for certificate or request generation. All crypto data is stored in an endian-agnostic file format portable across operating systems.

This application is intended as Certificate- and key-store and as signing application issuing certificates.

All data structures (Keys, Certificate signing requests, Certificates and Templates) can be imported and exported in several formats like DER or PEM. Import means reading a file from the file system and storing the data structure into the database file, while exporting means to write the data structure from the database file to the file system to be e.g imported into an other application.

When opening a new database the first time, it needs a password to encrypt the private keys in the database. This is the default password. Every time this database is opened the application asks for the password. This input dialog may be canceled and the database is still opened successfully. However, the access to the keys is not possible without supplying the correct database password every time a key is used.

The different cryptographic parts are divided over 5 Tabs: Keys, Requests, Certificates, Templates and Revocation lists. All items can be manipulated either by a context menu available by right-clicking on the item, or by using the buttons at the right border. Every item is identified by an internal name which is unique in one tab-view and is always shown in the first column.

RSA, DSA and EC keys

For creating certificates, keys are needed. All keys are stored encrypted in the database using the 3DES algorithm. The password can be changed for each certificate. The password type means:

common: The database password provided during database load private: The key has its own password, which is not stored by XCA. This can be set and reset via

the context menu of the key PIN: Security tokens are usually protected by a PIN No password: Public keys don't need a password

All keys carry a use counter which counts the times it is used. For new requests or certificates the list of available keys is reduced to the keys with a use counter of 0.

Generating Keys

The dialog asks for the internal name of the key and the key size in bits. For EC keys, a list of curves is shown. It contains all X9.62 curves. When importing an EC key with explicit curve parameters, the corresponding curve OID is searched and set if found. Even if the drop-down list only shows the most usual key sizes, any other value may be set here by editing this box. While searching for random prime numbers a progress bar is shown in the bottom of the base application. After the key generation is done the key will be stored in the database.

For every connected token providing the Key-generate facility an entry in the drop-down menu of the key types will be shown. It contains the name of the token and the valid key-sizes.

Key export

Keys can be exported by either selecting the key and pressing Export or by using the context-menu. This opens a Dialog box where the following settings can be adjusted:

filename Output format ( DER, PEM ) Public or Private Key PKCS#8 format Encryption of the exported file (yes/no)

The filename is the internal name plus a pem, der or pk8 suffix. When changing the file format, the suffix of the filename changes accordingly. Only PKCS#8 or PEM files can be encrypted, because the DER format (although it could be encrypted) does not support a way to supply the encryption algorithm like e.g. DES. Of course, encryption does not make sense if the private part is not exported.

CA (gnoMint X.509 CA Manager)

GnoMint is a tool for easily creating and managing certification authorities. It provides fancy visualization of all the pieces of information that pertain to a CA, such as x509 certificates, CSRs and CRLs.GnoMint is currently capable of managing a CA that emits certificates that are able to authenticate people or machines in VPNs (IPSec or other protocols), secure HTTP communications with SSL/TLS, authenicate and cipher HTTP communications through web-client certificates, and sign or crypt email messages.