What type of encryption function is used to generate a digital fingerprint for data?

Digital signatures

Digital signatures are a great example of where the hash function is used. Digital signatures allow us to sign a message in order to enable detection of changes to the message contents, to ensure that the message was legitimately sent by the expected party, and to prevent the sender from denying that he or she sent the message, known as nonrepudiation. To digitally sign a message, the sender would generate a hash of the message, and then use his private key to encrypt the hash, thus generating a digital signature. The sender would then send the digital signature along with the message, usually by appending it to the message itself.

When the message arrives at the receiving end, the receiver would use the sender’s public key to decrypt the digital signature, thus restoring the original hash of the message. The receiver can then verify the integrity of the message by hashing the message again and comparing the two hashes. Although this may sound like a considerable amount of work to verify the integrity of the message, it is often done by a software application of some kind and the process typically is largely invisible to the end user. A digital signature is considered legally binding and if it is lost or stolen must be revoked.

IV.A. Basic Principles

Digital signatures are very different from the handwritten signatures used on paper. Because data on a computer can be easily copied, an image of a person's written signature could be cut and pasted into a new document, making signature forgery a simple task. A different type of signature had to be designed for the digital realm.

Digital signatures can provide data integrity, authentication, and support for nonrepudiation. After a message has been signed, it cannot be modified without being detected. A valid digital signature can only be created by the original signer (i.e., cannot be forged) and thus can prove who signed the message.While signature creation relies on private information, signature verification must be possible with public information. The signer cannot later deny signing the message.

Public key cryptography can also be used for digital signatures. The RSA algorithm and DSA (Digital Signature Algorithm) are such examples.

2 Related Work

Digital signature is the de facto way to ensure the authentication, integrity, and nonrepudiation requirements. The Guidelines for Managing the Security of Mobile Devices in the Enterprise (Souppaya and Scarfone, 2013), developed by National Institute of Standards and Technology (NIST), suggested that digital signatures should be adopted for two purposes, namely, to ensure that only applications from trusted entities can be installed and to protect the integrity of the codes of these applications. A digital signature variant called mobile signature was defined by the European Telecommunications Standards Institute (ETSI) (2003). A number of models are proposed for the generation of digital signatures in the mobile environment. Specifically, digital signatures can be generated either on a mobile phone or on a SIM card on a mobile phone (Samadani et al., 2010). Digital signatures can be adopted in various mobile applications, including payment platforms (Wu et al., 2016), file transfer systems (Sayantan et al., 2015), and location proofs (Saroiu and Wolman, 2009). A survey of electronic signature solutions in mobile devices was carried out by Ruiz-Martínez et al. (2007), which discovered that mobile clients were able to generate digital signatures.

Recently, pairing-based cryptography (Paterson, 2005) has gain considerable attention thanks to its efficiency and improved security guarantees. For instance, Boneh et al. (2004a) introduced a short signature scheme (BLS) based on the Computational Diffie-Hellman (CDH) assumption on certain elliptic and hyper-elliptic curves. The signature length is half the size of a DSA signature (National Institute of Standards and Technology, 1992) for a similar level of security. Paterson and Schuldt (2006) proposed an efficient identity-based signature scheme (PS) based on Bilinear Decision Diffie-Hellman (BDDH) and Decision Linear (DL) assumptions with short signatures. This scheme enjoys the advantage that it is secure without relying on the so-called random oracle assumption (Bellare and Rogaway, 1993). In this chapter, we choose to investigate the practicality of these two well-known signature schemes on mobile devices.

XML Digital Signatures

XML Digital Signatures is a standard that allows for specifying the syntax and processing rules for attaching digital signatures to XML documents. An XML digital signature takes data objects, calculates a digest (fixed-length representation of a variable-length stream), and places the result into the signature element.

The standard allows XML to functionally sign itself over an insecure network. XML signatures can be attached to any form of digital content, including XML (data objects). An XML signature can sign more than one type of resource, such as HTML, binary-encoded data (GIFs and JPEGs), or an XML-encoded section of an XML file.

Digital Signatures

A digital signature is a means of verifying the authenticity and integrity of a message. This is achieved by using public key cryptography techniques combined with cryptographic hash functions. Com-bined with trusted time-stamping mechanisms, the digital signature can also be used to provide non-repudiation functions.

The digital signature process begins with creating a cryptographic hash of the message. This hash value is also known as a “digital fingerprint” and is a unique value. The digital fingerprint is then encrypted with the sender's private key, and the resulting value is appended to the message. This message is then sent to the recipient.

When the message arrives, the recipient decrypts the digital fingerprint appended to the message, creates a digital fingerprint of the message itself, and compares the two. If they match, the integrity of the message has been intact and the authentication of the sender is established. Please see Figure 3.6.

Digital Certificates

Digital signatures provided by ordinary users aren't very trustworthy, so a trusted authority is needed to provide them. The authority (which can be Windows-based) issues certificates, which are basically digitally signed containers for public keys and other information.

Certificates are used to safely exchange public keys, and provide the basis for applications such as IPSec, EFS, and smart card authentication. A CA hierarchy is structured with a root and one or more level of subordinates—three levels are common. The bottom level of subordinates issues certificates. The intermediate level controls policies.

Enterprise CAs require and use Active Directory to issue certificates, often automatically. Stand-alone CAs can be more secure, and need an administrator to manually issue or deny certificate requests.

• SAODV digital signatures

Digital signatures are used to protect the integrity of the nonmutable data in RREQ and RREP messages. So, they sign everything but the Hop Count of the AODV message and the Hash from the SAODV extension. AODV allows intermediate nodes to reply to RREQ messages if they have a “fresh enough” route to the destination. The problem is that a RREP message generated by an intermediate node should be able to sign it on behalf of the final destination. And, in addition, it is possible that the route stored in the intermediate node would be created as a reverse route after receiving a RREQ message (which means that it does not have the signature for the RREP). To solve this problem, two alternatives are offered. The first one is that, if an intermediate node cannot reply to a RREQ message because it cannot properly sign its RREP message, it just behaves as if it did not have the route and forwards the RREQ message. The second is that, every time a node generates a RREQ message, it also includes the RREP flags, the prefix size, and the signature that can be used (by any intermediate node that creates a reverse route to the originator of the RREQ) to reply to a RREQ that asks for the node that originated the first RREQ. Moreover, when an intermediate node generates a RREP message, the lifetime of the route has changed from the original one. Therefore, the intermediate node should include both lifetimes (the old one is needed to verify the signature of the route destination) and sign the new lifetime. In this way, the original information of the route is signed by the final destination and the lifetime is signed by the intermediate node. The later version has two signatures and uses RREQ and RREP Double Signature Extension (refer to [33] for detail).

When a node receives a RREQ, it first verifies the signature before creating or updating a reverse route to that host. Only if the signature is verified will it store the route. If the RREQ was received with a Double Signature Extension, then the node will also store the signature for the RREP and the lifetime (which is the “reverse route lifetime” value) in the route entry. An intermediate node will reply to a RREQ with a RREP only if it fulfills the AODV's requirements to do so and the node has the corresponding signature and old lifetime to put into the Signature and Old Lifetime fields of the RREP Double Signature Extension. Otherwise, it will rebroadcast the RREQ. When a RREQ is received by the destination itself, it will reply with a RREP only if it fulfills the AODV's requirements to do so. This RREP will be sent with a RREP Single Signature Extension.

When a node receives a RREP, it first verifies the signature before creating or updating a route to that host. Only if the signature is verified will it store the route with the signature of the RREP and the lifetime.

Autoruns

Autoruns.exe [1] is a tool written by Mark Russinovich of Microsoft, formerly SysInternals. Autoruns is a great GUI tool that allows you to see a lot of the various locations on a system, where various programs can be run automatically, with little to no user interaction. Figure 2.1 illustrates the GUI for Autoruns, version 10.02, run on a Windows XP system.

Figure 2.2 illustrates the Autoruns GUI when the tool is run on Windows 7. The most notable addition to GUI is the available tab named SideBar Gadgets.

Figures 2.1 and 2.2 shows that there are a number of locations, many of which (albeit not all) are found in the Registry, that allow programs to start automatically, often with no more interaction from the user than booting the system or logging into the system. Autoruns is a very useful tool for troubleshooting systems, as well as for locating malware and suspicious applications, during incident response. In fact, Autoruns comes with a command line companion tool called autorunsc.exe (not the addition of the “c” in the filename), both of which are intended to be run on live systems. Incident responders can include this tool in batch files used for collecting information from systems and gain a considerable amount of insight into what may be happening on the system. This tool can also be deployed remotely by responders using the Psexec.exe (remote command execution tool) also available from Microsoft. As of version 10, Autoruns includes the capability to analyze off-line Registry files; the administrator simply selects the appropriate locations via the “Offline System” dialog box illustrated in Figure 2.3.

To examine off-line files using autorunsc.exe, use the “-z” switch. To see other available options for use with autorunsc.exe, simply type autorunsc /? at the command prompt.

Although both of these tools are extremely thorough in the locations from which they extract data, there are a couple of things to consider when deploying these tools. First, none of the tools collects Registry key LastWrite times. Registry key LastWrite times can be extremely valuable when conducting incident analysis or building a timeline of activity from affected systems. Second, all the entries are simply presented, and there's very little explanation as to what many of the tabs refer to or how the information they provide can be used, particularly by less experienced analysts. In short, this can provide an analyst with considerable amounts of data which she has no idea how to use. Finally, these tools all employ an end-user license agreement (EULA) that must be agreed by the user before the tool will run for the first time on the system. When the tool is run and the EULA is accepted, a Registry key is created for the tool, as illustrated in Figure 2.4.

In order to run autorunsc.exe successfully on a system for the first time during incident response, a command line similar to the following, accepting the EULA, should be used:

autorunsc -v -a /accepteula

The “/accepteula” switch will automatically accept the EULA; if this is not used, a dialog box will appear and will wait for user interaction to accept the EULA before proceeding.

Autorunsc.exe and Digital Signatures

The “-v” switch used with autorunsc.exe tells the tool to verify digital signatures of files. There are a couple of things that analysts need to keep in mind when using this switch and viewing the output of the tool. First, in order to verify a file's digital signature, it has to be opened and accessed, modifying the last accessed time of the file. Second, around June 2010, I began to notice an increase in the number of articles in the media where malware files were found to use legitimate, albeit stolen digital signatures. I would not suggest that this is when it started; more accurately, this is when I first started to notice more articles in the media. Specifically, the malware known as Stuxnet was reported to use legitimate digital signatures from RealTek Semiconductor Corp.and JMicron.

The point of mentioning these three items is not, say, that you shouldn't use autorunsc.exe; rather, the point is to educate the user of what to expect when using the tool. As I mentioned, these two tools are very thorough and collect a great deal of valuable data. However, using these tools on a system will leave the artifacts described above.

Applying XML Digital Signatures

Although encryption is an important step in securing your Internet-bound XML, at times you might want to ensure that you are receiving information from the person you think you are. The W3C is also in the process of drafting a specification to handle digital signatures.

XML digital signatures digitally sign an element or, more typically, the entire XML document. Digitally signing an XML document is the process of creating a hash or fingerprint of the document and then encrypting this hash with a private key. This process prevents anyone from changing the document undetected; it also proofs the document sender's identity. The technology and algorithms to create a hash, as well as a discussion of asymmetrical encryption (the use of public and private keys), are presented in detail in Chapter 4.

Signing XML Data

Summary:	XML digital signatures are useful to verify the integrity of data and authenticity of the sender and for nonrepudiation
Threats:	Data corruption, man-in-the-middle attacks, brute-force attacks

A digitally signed XML document provides the following benefits:

▪

Integrity The document is exactly as it was when it was signed. The document cannot be modified in any way after signing, without invalidating the signature.

▪

Authentication The document came from the signer and no one else.

▪

Nonrepudiation The document signer cannot deny signing the document.

A digitally signed document, however, is not private. You should apply XML encryption if privacy is important. Candidates for digitally signed documents are documents such as contracts and agreements, for which it is important that the details of the contract did not change and the sender cannot deny that he or she sent the document.

XML Digital Signatures Specification

The XML digital signature specification is a fairly stable working draft. Its scope includes how to describe a digital signature using XML and the XML-signature namespace. Code should generate the signature from a hash over the canonical form of the manifest, which can reference multiple XML documents. To canonicalize something is to put it in a standard, general-use format. Because the signature is dependent on the content it is endorsing, a signature produced from a noncanonicalized document could possibly be different from that produced from a canonicalized document. Remember that this specification is about defining digital signatures in general, not just those involving XML documents—the manifest may also contain references to any digital content that code can address, even part of an XML document.

Knowing how digital signatures work is helpful in better understanding this specification. Digitally signing a document requires the sender to create a hash of the message itself and then encrypt that hash value with his own private key. Only the sender has that private key, and only he can encrypt the hash so that it can be unencrypted using his public key. The recipient, upon receiving both the message and the encrypted hash value, can decrypt the hash value, knowing the sender's public key. The recipient must also try to generate the hash value of the message and compare the newly generated hash value with the unencrypted hash value received from the sender. If the hash values are identical, it proves that the sender sent the message, because only the sender could encrypt the hash value correctly. The XML digital signature specification is responsible for clearly defining the information involved in verifying digital certificates.

XML digital signatures are represented by the Signature element, which has the following structure:? denotes zero or one occurrence, + denotes one or more occurrences, and * denotes zero or more occurrences.

The XML digital signature specification is in the recommended stage and is ready for adoption. For further details, you can review the official W3C XML Signature Syntax and Processing specification found at www.w3.org/TR/xmldsig-core. Figure 8.9 shows the XML digital signature specification syntax.

Figure 8.9. XML Digital Signature Structure

The following described elements are the most notable of the specification:

▪

Signature The primary construct of an XML signature. This topmost element holds all the other signature elements.

▪

SignedInfo The parent element that contains the canonicalization and signature algorithm elements.

▪

CanonicalizationMethod An element that describes the algorithm that prepares the data for signing. Canonicalization is a necessary and important transformation to convert the data to standard format that will yield that same hash results, regardless of the computing environment. For example, a Windows environment and a UNIX environment use different key codes to represent carriage returns. Canonicalization will standardize these key codes.

▪

SignatureMethod The algorithm used to sign the data. This may be combination of a digest algorithm, an encryption algorithm, or a padding algorithm.

▪

SignatureValue The actual digital signature, base-64 encoded.

▪

DigestMethod The algorithm applied to the data, after any defined transformations are applied, to generate the DigestValue. Signing the DigestValue binds resource content to the signer's key.

▪

DigestValue The value generated by applying the DigestMethod to the data object to be signed.

▪

KeyInfo The parent element that contains details of the key to be used to validate the signature.

There you go—everything you need to verify a digital signature in one nice, neat package. To validate the signature, you must digest the data object referenced using the relative DigestMethod. The reference is valid if the digest value generated matches the DigestValue specified. Then, to validate the signature, obtain the key information from the SignatureValue and validate it over the SignedInfo element.

XML Digital Signature Example

As an example, let's take the role of a car dealership. We would like to submit details and prices of our cars to an Internet search engine. The search engine requires our data in XML so that it can display the details in a variety of formats and views. However, we are concerned that the unscrupulous may modify the details of the data, either in transit to the Internet search engine or on the search engine itself. As a car dealership, we are not bothered that anyone can view the car details as we send them to the search engine; in fact, the more viewers, the better! We decide to use an XML digital signature to prevent the undetected modification of our car details. Figure 8.10 shows an example of a document ready to digitally sign.

Figure 8.10. XML Document to Be Digitally Signed

The example code in Figures 8.11 and 8.12 demonstrates how to read an XML document and dynamically create a digital signature. For simplicity, code generates the encryption key. Ordinarily, code would read the key from a secure location.

Figure 8.11. Creating an XML Digital Signature: C#

Figure 8.12. Creating an XML Digital Signature: VB.NET

Figure 8.13 shows the XML document of Figure 8.10 after digitally signing.

Figure 8.13. XML Digitally Signed Document

Creating a digitally signed XML document is only half the process. The document recipient should now verify that the signature is valid and the document as not been modified. Continuing with our car dealership example, the Internet search engine to which we submitted our signed document must now validate the signature. If the document's signature is valid, the search engine can guarantee that the document has not been modified. Figures 8.14 and 8.15 show example code to validate an XML signed document.

Figure 8.14. Validating an XML Digital Signature: C#

Figure 8.15. Validating an XML Digital Signature: VB.NET

You will probably see an increase in the use of encryption and digital signatures when the W3C group finalizes both the XML encryption and XML digital signature specifications. Both specifications provide a well-structured way to communicate their respective processes, and as always with ease of use comes adoption. Encryption ensures that confidential information stays confidential through its perilous journey over the Internet. Digital signatures ensure that you are communicating what and with whom you think you are. Yet both these specifications have some evolving to do, especially when they are used concurrently. There's currently no way to determine if a document that was signed and encrypted was signed using the encrypted or unencrypted version of the document. Typically, these little bumps find a way of smoothing themselves out over time.

Security Policies

▪

Use strong asymmetrical algorithms to ensure the privacy of data.

▪

Validate the signature of signed documents.

▪

Use encryption for sending private data. Digital signatures do not make a document private; they merely validate the source integrity.

What Is a Digital Signature Concept?

The digital signature is a method used to make sure that the person who sends us an encrypted message is the same person whom he/she pretends to be. This could be achieved (from the sender side) by encrypting the message using a private key (sender private key) and then encrypting the result again using the receiver’s public key. When the receiver receives the message, he/she needs to decrypt it using his/her private key, and then decrypt the result again using the sender’s public key. The receiver can then read the message and also make sure it is originated from a genuine sender.

Gpg4win implements the digital signature concept by using Secure/Multipurpose Internet Mail Extension (S/MIME—X509) as in Fig. 5.71. Your key must be authenticated by an accredited organization before it can be used. The certificate of this organization in turn was authenticated by a higher-ranking organization and so on, until we arrive at the so-called root certificate. This hierarchical chain of trust usually has three links:

The root certificate

The certificate of the issuer of the certificate (the certificate authority (CA))

Your own user certificate

A second alternative and noncompatible notarization method is the OpenPGP standard. It does not build a trust hierarchy, but rather assembles a Web of trust. The web of trust represents the basic structure of the nonhierarchical Internet and its users. For example, if User B trusts User A, then User B could also trust the public key of User C, who does not know if this key has been authenticated by User A.

Therefore OpenPGP offers the option of exchanging encrypted data and emails without authentication by a higher-ranking agency. It is quite sufficient if you trust the email address and associated certificate of the person you are communicating with.

Gpg4win allows for the convenient and parallel use of both methods when signing encrypting messages.