Literature ReviewDigital SignatureA digital signature is an electronic form of a signature that can be used to authenticate the identity ofthe sender of a message or the signer of a document, and also ensure that the original content of themessage or document that has been sent is unchanged. Digital signatures are easily transportable andcannot be imitated by someone else. The ability to ensure that the original signed message arrivedmeans that the sender cannot easily disclaim it later.Generating Digital SignatureLet us consider that B wants to digitally sign a document “m”. To sign the document, B simply uses hisprivate 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 ofbeing 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 havepossibly 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 computedmessage is identical or exactly matched to obtained plane message, he/she can argue that B could havesigned 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.Ifthe original document, m, is ever modified to some alternative form, m’, the signature that B createdfor 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 arecomputationally expensive. When digitally signing a really important document, say a merger betweentwo large multinational corporations, computational cost may not be important. However, manynetwork devices and processes (for example, e-mail user agents exchanging e-mail) routinely exchangedata 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 hassigned 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 canbe overkill. A more efficient approach, using message digests, can accomplish these two goals withoutfull message encryption.A message digest (also known as hash value) is in many ways like a checksum. Message digestalgorithms take a message, m, of arbitrary length and compute a fixed- length “fingerprint” of the dataknown as a message digest, H (m). For example, a person can be uniquely identified by his/ her fingerprint. Similarly a document can be uniquely identified by the hash value. The message digest protectsthe data in the sense that if m is changed to m’ (either maliciously or by accident) the H (m), computedfor the original data (and transmitted with that data), will not match the H (m’) computed over thechanged data, m’. Given these considerations, the three important properties of message digest to benoted 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 goalhere is that rather than having B digitally sign the entire message by computing Kb-(m), he should beable 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-256etc. MD5 take arbitrary length message and compute fixed length (128 bits) hash value and similarlySHA-256 computes fixed length (256 bits) message digest or hash value.
Digital CertificateA Digital Signature Certificate authenticates your identity electronically. It also provides you with ahigh level of security for your online transactions by ensuring absolute privacy of the informationexchanged using a Digital Signature Certificate. You can use certificates to encrypt information suchthat only the intended recipient can read it. You can digitally sign information to assure the recipientthat 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 ofelectronic keys - public and private keys - and this association is endorsed by the CA. The certificatecontains information about a users 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 areused by browsers and servers to encrypt and decrypt information regarding the identity of thecertificate user during information exchange processes. The private key is stored on the users computerhard disk or on an external device such as a token. The user retains control of the private key; it canonly be used with the issued password.The public key is disseminated with the encrypted information. The authentication process fails ifeither one of these keys in not available or do not match. This means that the encrypted data cannot bedecrypted 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:
DBsign uses various cryptographic modules. DBsign can import and usePKCS12 ”software tokens”.Cryptographic Modules, Security and Cost Optimization .The security of a digitalsignature system is determined by several criteria. Of primary concern is theprotection of private key material. The security of a user’s digital signature isdirectly related to the methods used to protect the user’s private key and theprivate keys of the CAs in the certificate chain. Cryptographic modules are used toprotect the private key and to perform all cryptographic operations. Softwarecryptographic modules are less expensive, but also less secure. Hardware tokens aremuch more secure, but can be more expensive. Hardware modules can also be muchfaster than software modules. The digital signature system must be able to use bothsoftware and hardware cryptographic tokens. Sensitive data, such as large dollar-value financial transactions, translates into higher risk and therefore a highersecurity requirement.DBsign utilizes cryptographic modules that can accommodate both low and high-risktransactions.DBsign supports Class 3 and Class 4 certificates (stored on smart cards, PC Cardsor USB tokens).The digital signature system must be able to enforce the use of higher securitycryptographic modules for higher risk transactions while allowing less expensivecryptographic modules to be used for lower risk transactions.DBsign enforces this in two stages. A user is not able to sign a high-risktransaction (such as payment authorization) with a low security cryptographicmodule (such as a diskette). When the signature is verified, DBsign determines thata transaction was signed with a cryptographic module of the appropriate securitylevel. The ability to use cryptographic modules of varying security levelsand the ability to enforce a policy for their use is crucial to optimizing thesecurity/cost tradeoff. The digital signature system must provide an interface that allows the use of
third-partysecurity products.Another important part of reducing cost and risk is vendor independence. DBsignsupports the use of third-party cryptographic modules and/or toolkits. An interfaceto external products and modules allows the digital signature system to takeadvantage of the latest technological developments and provides a means ofadaptation to a changing environment.The Signing and Verifying Process Signing data and verifying signatures in arelational database environment introduces several security and interoperabilityconcerns.The digital signature system must provide a method for specifying which data toinclude in the data to be signed.DBsign allows application designers to decide which data elements need to beprotected and gives them the ability to exclude some data elements from inclusionin the data to be signed. By protecting only the data elements that need to beprotected, performance is increased because less data flows across the network.The digital signature system must provide a method for modifying the data toinclude in the data to be signed without violating the integrity of existingsignatures. As new functionality is added to systems, the data requirements forthe transactions in the system may change. Sometimes data elements that need to beprotected by the digital signature are added to a system. DBsign allows thesignature composition to change without compromising the integrity of existingtransactions.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 anapplication table (or stored procedure object) into the user’s private table spaceand have that table be used by an application. This allows the users to alter theinformation in that table and possibly commit fraud. DBsign provides a mechanismto prevent such attacks.The digital signature system must allow the representation of data elements to bespecified.When verifying a signature, the each data element must be in exactly the sameformat 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 differencebetween “0.8” and “0.85” percent can be significant. DBsign allows therepresentation 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 othersystems can reproduce the same data to be signed if necessary. This enablesdifferent applications to be inter operable with respect to the format of the datato 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 enablesigningand verifying automatically.
DBsign supports the integration of digital signatures and signature verificationsinto the application work-flow enabling signatures and signature verifications tooccur at strategic steps during the work-flow. The user does not need to be giventhe option to “sign” or “not sign” or to “verify” or “not verify”.If signature verification fails because data was changed, the digital signaturesystem 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 aSQL script. Such changes may be valid, but may modify data that is protected by adigital 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 ifthe change was the result of an innocent correction, or if an attacker hasattempted fraud. DBsign enables user to view the data as it was signed and as it currentlyexists in the database. The digital signature system must include a timestamp with the signed data to showwhen the signature was generated. This timestamp must be protected by the digitalsignature.DBsign uses signature timestamps. Protecting the timestamp with the digitalsignature ensures that the timestamp cannot be altered.The digital signature system must verify that the signer’s certificate was validat the time of signing.
Every X.509 certificate includes a validity period. Signatures generated outside ofthe validity period of the signer’s certificate should produce an error whenverified.DBsign compares the signature’s timestamp to the validity period of the signer’scertificate to make this determination.The digital signature system must retrieve the current date and time from acentral, trusted source such as the database server or a timestamp authority.Reliance on the client side clock presents a security risk because it can bealtered by an attacker to misrepresent the date and time of signing. The digitalsignature system must not use the client workstation’s internal clock forsignature timestamps or certificate validity checks. DBsign retrieves the timestampfrom the database server.Upon signature verification, the digital signature system must verify that thesigner’scertificate has not been modified or revoked. The certificate chain should beverified upto and including the root certificate.To ensure that a user’s identity cannot be forged, all certificates are digitallysigned by the issuing CA. Each CA certificate is signed by a higher level CA. Theroot CA signs its own certificate. The root certificate is the only certificatethat is explicitly trusted. All other certificates are trusted if they were issuedby a CA subordinate to the root. Each CA publishes a Certificate Revocation List(CRL) and/or provides an online certificate status mechanism. DBsign checks thisCRL. 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 rootcertificates and should only honor certificates from the trusted hierarchiesdefined 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 shouldnot be permitted to digitally sign documents with certificates from an untrustedhierarchy. Upon verification, DBsign does not honor a signer’s certificate if itis not from a trusted hierarchy. DBsign does not add a trusted root certificate tothe list of trusted roots without prompting the user. The user must beauthenticated (via a password or a proof of private key test) before adding a newroot certificate to the list. The list of root certificates should initiallyinclude 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 applyingcryptography to the contents of the clipboard.XCA - X Certificate and key managementXCA creates and manages Certificate authorities and helps the user to and manageskeys, 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 invarious 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 easycompany-wide use there are customiseable templates that can be used for certificate or requestgeneration. All crypto data is stored in an endian-agnostic file format portable across operatingsystems.This application is intended as Certificate- and key-store and as signing application issuing certificates.All data structures (Keys, Certificate signing requests, Certificates andTemplates) can be imported and exported in several formats like DER or PEM. Importmeans reading a file from the file system and storing the data structure into thedatabase file, while exporting means to write the data structure from the databasefile 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 theprivate keys in the database. This is the default password. Every time thisdatabase is opened the application asks for the password. This input dialog may becanceled and the database is still opened successfully. However, the access to thekeys is not possible without supplying the correct database password every time akey is used.The different cryptographic parts are divided over 5 Tabs: Keys, Requests,Certificates, Templates and Revocation lists. All items can be manipulated eitherby a context menu available by right-clicking on the item, or by using the buttonsat the right border. Every item is identified by an internal name which is uniquein one tab-view and is always shown in the first column.RSA, DSA and EC keysFor creating certificates, keys are needed. All keys are stored encrypted in the database using the 3DESalgorithm. 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 dont need a passwordAll keys carry a use counter which counts the times it is used. For new requests or certificates the list ofavailable keys is reduced to the keys with a use counter of 0.
Generating KeysThe dialog asks for the internal name of the key and the key size in bits. For EC keys, a list of curves isshown. It contains all X9.62 curves. When importing an EC key with explicit curve parameters, thecorresponding curve OID is searched and set if found. Even if the drop-down list only shows the mostusual key sizes, any other value may be set here by editing this box. While searching for random primenumbers a progress bar is shown in the bottom of the base application. After the key generation is donethe key will be stored in the database.For every connected token providing the Key-generate facility an entry in the drop-down menu of thekey types will be shown. It contains the name of the token and the valid key-sizes.Key exportKeys 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, thesuffix of the filename changes accordingly. Only PKCS#8 or PEM files can be encrypted, because theDER format (although it could be encrypted) does not support a way to supply the encryption algorithmlike 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. Itprovides 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 ableto authenticate people or machines in VPNs (IPSec or other protocols), secure HTTPcommunications with SSL/TLS, authenicate and cipher HTTP communications throughweb-client certificates, and sign or crypt email messages.