This is a literature review of Digital Signature. It contains the similar system details.

1. 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

2. 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.

3. 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-Sign
2. DB-sign
3. KGpg
4. XCA
5. CA (gnoMint X.509 CA Manager)
DBsign:

4. 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

5. 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

6. 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.

7. 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.

8. 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

9. 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.

10. 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.

11. 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.