FEATURE: SECURITy

A Digital Signature
Architecture for
Web Apps
Harigopal K.B. Ponnapalli and Ashutosh Saxena, Infosys, India

This digital signature architecture provides browser-agnostic,

clientside signature components and generic server-side signature
validation components to help integrate signatures into Web
applications. The authors also discuss ways to extend HTML syntax to
support signatures.

I
n today’s competitive business world, in architecture that provides browser-agnostic, which enterprises
must extend their busi- client-side signature components and generic ness environments over the Web for
con- server-side signature validation components to sumers, employees, and partners, digital help integrate
signatures into Web applications.
security will play a pivotal role in building trust
and credibility. Secure sockets layer (SSL) over Digital signature technology can help address
HTTP (HTTPS) is the standard method used to nonrepudiation in addition to satisfying the
secure Web content. However, SSL addresses authentication and integrity requirements of
only a subset of security requirements. It can digital content. Here, we discuss a digital
establish a reliable private connection and signature
authenticate peer identities but doesn’t offer Signature Issues in Web Apps
nonrepudiation, which is an equally critical Using digital signatures and SSL in combination
security requirement for today’s business complements each technology’s innate capabilities. A
applications. Also, because SSL is a transport- digital signature, which requires a public key infrastructure
layer protocol, it only protects data while in (PKI), is a well-accepted, legally valid, electronic
transit between the client (browser) and Web equivalent of a handwritten signature in most parts of the
server. It doesn’t cover requirements vis-à-vis globe (see the “Digital Signatures” sidebar for more
end-to-end message-level protection. information). The process (outlined in the sidebar) is fairly

42 IT Pro
 Digital Signatures
D
igital signatures can replace handwritten signatures
in workflow-based Web transactions, resulting in
completely automated, faster, and efficient
workflows. Web applications across several industry
segments can benefit from digital signatures.
Use Cases
In the insurance sector, time-consuming, paperintensive
March/April
review, approval, and2013 Published by the IEEEServer-Side
archival processing of insurance
documentation can be replaced with faster, low-cost, and
digitally signed electronic documents. In the government
sector, faster citizen service is possible with paperless e-
governance, replacing handwritten signatures with digital
signatures. Furthermore, a more secure e-commerce
system can be built if consumers digitally sign the
purchase requests made on commerce portals.
In e-banking systems, the use of digital signatures
facilitate online loan applications, account openings,
approvals, and other financial transactions, mitigating
paper dependence and helping banks stay productive,
competitive, and compliant with regulatory
requirements.
In healthcare, digitally signed electronic documents
enable paperless automated operations and business
processes in hospitals and medical centers. They also
help such facilities comply with regulations, such as the
Health Insurance Portability and Accountability Act.
Client-Side Digital Signatures
In Web applications with an architecture based on a
client-side digital signature, the process starts with the
user filling in a Web form and initiating the signature
process. The client signature component prompts the
user to select a private signing key from a secure private
key storage. Then, the application creates a digital
signature for the Web content and submits it to the Web
server. A server component verifies the signature for its
authenticity and integrity, and validates the certificate
to ensure it was issued by
simple, but it becomes complicated when implemented in a
Web application for two main reasons.
First of all, the HTML specification doesn’t include
signature support.1 Using third-party signature tools2,3 to
sign Web content limits Web applications to certain
browsers and operating systems.
Second, multiple signature-representation standards exist
for different business contexts— such as the Public-Key
Cryptography Standard #7 (PKCS#7), 4 Cryptographic
Message Syntax (CMS),5 and XML Digital Signature
(XML DSig).6 However, there’s no single standardized
interface that lets Web applications use these varied
signature format standards in a pluggable, flexible manner.
a trusted certification authority. The digital signature
and Web content are securely logged in persistent
storage. In the case of a nonrepudiation dispute at a
later date, the digital signatures can be retrieved from
the secure storage and verified to prove which users
participated in the transaction.
Computer Society Digital Signatures
1520-9202/13/$31.00 © 2013 IEEE
An alternative to the client-side signature architecture is
to employ a server-side signature generation
mechanism,2 where the private signing keys of all users
are stored in a secure server-side store. When the
signature is required, the user is authenticated by a
server through a mechanism other than a digital
signature, such as a password, and the server-side
cryptomodule retrieves the user’s private key and
creates the signature on the server content on behalf of
the user.
Although server-side signature generation has its
merits, including ease of use and lower maintenance
and deployment costs, it increases the complexity of
the server-side infrastructure in terms of protection
and performance needs. High protection is required to
secure access to the server-side key store, which often
becomes a target for attacks. Also, the legal validity
must be analyzed in different geographies, because the
digital signature creation is delegated to the server by
the user. A detailed discussion of the server-side
signature mechanism is beyond the scope of this
article.
References
1. Information Technology—Open Systems Interconnection
— The Directory: Authentication Framework, International
Telecommunication Union recommendation X.509, Aug.
1 2005; www.itu.int/rec/T-REC-X.509.
2. “Digital Signatures and the Hidden Costs of PKI,” ARX,
Aug. 2010; www.arx.com/resources/white-papers/
digital-signatures-and-the-hidden-costs-of-pki.htm.
Similarly, there are multiple private key storage
techniques (for hardware and software) and
formats—such as the Windows key store,7 Java
key stores (JKS),8 PKCS#11,9 and PKCS#1210—
and varied certificate-status verification
mechanisms, such as the Certificate Revocation
List (CRL)11 and Online Certificate Status
Protocol (OCSP).12 It’s important to have
standardized interfaces to seamlessly consume
these underlying PKI services in Web
applications.
We propose addressing these issues by
amending the HTML specification to support the
creation of digital signatures for Web content.
computer.org/ITPro 43
 FEATURE: SECURITy
and OCSP), and certificate-pathbuilding
algorithms, such as PKI X.509 (PKIX;
http://datatracker.ietf.
org/wg/pkix/charter).

A Java-Based Digital
Signature Architecture
In the absence of standards for browsers
to handle signatures in Web content,
Java is a good choice for developing a
browser-agnostic signature architecture,
because Java applet is the client
technology most commonly supported
by popular browsers. Furthermore, it
has

• feature-rich support for handling

signatures;
• built-in standardized API support for
dealing with multiple private key
stores in either the software or
hardware;
Figure 1. Digital signature architecture overview.

There’s one initiative to use XML digital signature syntax

to sign HTML content,13 but it’s still primitive and specific
to the XML signature standard. So, for now, our
architecture offers an interim solution.

Key Requirements
In defining our digital signature architecture, we
considered several key requirements. First, the
signature creation and verification functionality
had to be browser-agnostic so it works in all
popular browsers (Microsoft IE, Firefox,
Chrome, and so on). Second, we needed a
centralized, parameter-driven architecture that
could address varying business needs depending
on the underlying PKI services available. Third,
we needed the flexibility to digitally sign the
Signature Signature
Web form content in its entirety or selectively. Certificate
generator validator
We also needed extensible validator
(PKCS7, XML (PKCS7, XML for private
support
(CRL/OCSP )
key DSig)
store formats—such as the Windows key
DSig)
store, PKCS#11, PKCS#12, and JKS—both on
software and hardware (smartcards, USB tokens,
and so on). Finally, we needed configurable
support for multiple signature format standards
(such as PKCS#7 and XML DSig), certificate-
status verification mechanisms (such as CRLs

Configuration Certificate and Secure private Signature

repository CRL repository key storage storage and
(database, (database, (PKCS12, archival
files) directory, PKCS11, (database,
files) Windows) files)

44 IT Pro March/April 2013

 Offline
Certificate and
signature
CRL update
verification
utilities
utilities

• built-in support for a standardized XML digital

signature API and commercial and open source
PKCS#7/CMS libraries (see www.bouncycastle. org);
and
• ready support for certification path validations using
OCSP and CRL.14

Although we discuss a Java-based architecture, it’s easy to

develop the server-side solution in other popular Web
technologies, such as .NET, which also provide rich
support for cryptographic functionality. Figure 1 depicts
the important building blocks of the architecture.
Using a factory design pattern is a good choice for a
flexible and dynamic invocation of signature functionality
from multiple options, such as signature syntax standards,
key store formats, and certificate validation. The factory
pattern allows dynamic instantiation of objects with
different behavior but with the same interface methods.
It’s important to carefully define the interface with
appropriate method signatures at a sufficiently abstracted
level. Specialized behaviors can be derived by
implementing these abstract interfaces. Similarly, the
parameters needed for these standards might vary widely,
so it’s appropriate to abstract the parameters into a separate
abstract class. Each standard that requires a specific

SignatureStandardFactory
SignatureStandard public SignatureStandard getInstance(String standardName)
public boolean verify()
public boolean verify (byte[]
dataSigned)
public X509 Certificate[]
getCertificates()
public X509CRL[]
GetCRLs()
XMLDSigParameters StandardParameters
public void setCertsAndCRLs(X509Certificate[]
,
public void sign(byte[] X509CRL[])
, dataToBeSigned, PrivateKey privKey)

PKCS7Parameters
PKCS7Standard XMLDSigStandard public void getOutputEncoding()
public PKCS7Standard(PKCS7Parameters) public XMLDSigStandard(XMLDSigParameters) public boolean isCertificateChainIncluded()
public boolean isAttachedSignature()
public void setOutputEncoding(String encodingFormat)
public void setCertificateChainIncluded(boolean includeChain)
public void setAttachedSignature(boolean attachedSignature)
public void setVerifyChain(boolean verifyCertChain)
Configurator public boolean getVerifyChain()
public void setCertVerficationMechanism(String mechanism)
public String getCertVerificationMechanism()

Aggregation
KeyStore Realization
Generalization
Interface
Windows KeyStore PKCS12KeyStore PKCS11KeyStore JavaKeyStore
Dependency

Figure 2. Digital signature architecture class diagram.

parameter set can provide its implementation of this
abstract class. The idea for the architecture is to reuse
existing standardized Java APIs wherever available and
define new ones wherever needed. Figure 2 provides a
definition of some important classes.
There’s a compelling need to define a centralized,
configuration-driven architecture that drives the behavior
of both client and server modules to meet varying business

computer.org/ITPro 45
 FEATURE: SECURITy
needs. In the following, we discuss the corresponding
modules along with their functionality (excluding GUI
components, in an effort to stay focused on key aspects
related to signatures).
Configuration Repository
Digital signature requirements vary according to the
business needs, available PKI services, local regulations
and standards, organization security policies, and so on.
The configuration repository is a centralized store for all
configuration parameters and is the key component for a
centralized, parameter-driven architecture. The repository
can be a database, file system, or directory.
The Configurator class depicted in Figure 2 reads all
configuration-related information and supplies it to the
signature creation and verification components. In one
possible implementation, the Configurator can be as simple
as a Java properties class that reads key value properties
from a configuration repository. Table 1 provides a brief
description of some important configuration parameters
considered, but it’s not an exhaustive list.
46 IT Pro March/April 2013
Signature Generator
This component creates the signature. Sun Java
has a signature factory that helps in instantiating
signature objects supporting specific algorithms,
such as RSA and XML digital signatures.
However, Java doesn’t have a standardized
interface for CMS/PKCS#7. To provide
pluggable and extensible support for these
multiple standards, a factory design pattern is
followed by our architecture (Figure 2).
SignatureStandardFactory is a factory that helps
in creating an instance of a SignatureStandard
object based on the signature standard that’s
configured. SignatureStandard is a generic
interface that captures the functionality of any
digital signature standard (such as signature
creation or verification). Different standards, such
as PKCS7Standard (for PKCS#7) and
XMLDSigStandard (for XML DSig), implement
standard-specific functionality for the interface
methods. The behavior of SignatureStandard
objects can be customized by supplying
StandardParameters object (such as
PKCS7Parameters or XMLDSigParameters)
corresponding to the particular signature
standard. This gives applications the flexibility to
use different signature standards without code
changes.
Java Applet code on the client can use this signature
generator component to generate a
 Table 1. Important configurable parameters.
Parameter Description

Key stores – Instruct client to select certificates from a configured key store
– Options include Windows, JKS, JCEKS, PKCS#12, or PKCS#11
Signature format – Standard format for signature representation
– Affects both client and server modules

– Options include PKCS#7 and XML DSig (this can be further populated when support for any other standard
formats is built)
Certificate chain – Instructs whether to include the entire certificate chain, the entire chain excluding the root, or only the user
certificate
– Helps save memory and network bandwidth in cases where the rest of the certificates are retrievable –
Affects both client and server modules
Content present – Affects both client and server behavior
– Instructs whether to include the data signed as part of signature content (for example, in PKCS#7,
content can be excluded in a scenario where content can be retrieved directly from the Web form
by the verification module)
– Saves memory and network bandwidth.
Signature algorithm – Affects both client and server behavior
– Indicates which signature algorithm (such as RSAwithSHA or DSAwithSHA) to use
Certificate validation – Affects server-side validation behavior
– Indicates the details of the certificate-status validation mechanism, like choosing CRL or OCSP and
their corresponding URLs (it’s also possible to have this check on the client side if such service is feasible)
Trusted CAs – Affects both client and server behavior
– Indicates the list of trusted and accepted certification authorities
Output encoding – Affects both client and server behavior
– Indicates the output encoding format for signature (for example, in case of PKCS#7, it can be either
Distinguished Encoding Rules15 or Base6416 encoding)
Signature holder – Affects both client and server behavior
– T he signature generated can be assigned by the client to this HTML form field, which is accessed to verify the
signature on the server
signature in the Web content. Other client-side The server-side module renders the Java applet tag with
technologies required to digitally sign Web content within configuration information read from the Configurator. The
browsers include JavaScript and Java applets. Java applet uses this information to generate a signature on
JavaScript is supported by all popular browsers and the content to be signed. The created signature can be
helps dynamically prepare the content to be signed. supplied to the server either directly by applet or by
Developers can write generic JavaScript functionality to assigning it to a predefined field (the signature holder
retrieve data to be signed from the form fields. This library specified in the configurable parameters in Table 1) within
interacts with the Java applet to invoke signature the HTML form. Client-side modules are written in Java
functionality and supply the content to be signed to the and JavaScript and can be used in a browser-agnostic
applet. manner in all Web applications, irrespective of the server-
Java applets are Java applications that run in side language.
the browser in a secure sandbox environment. An
applet-based solution offers Signature Validator
This component is part of SignatureStandardFactory and
• a browser- and platform-agnostic solution that helps verify the signature according to the configuration
runs in all popular Web browsers; read from the Configurator. The signature validator invokes
• easy maintenance, because the solution only certificate-status verification modules as per the
needs to be updated on the server side; configuration.
• rich built-in support for PKI in Java; and
• access to local system resources (such as Certificate Validator
This component helps validate the certificate chain in
private key files), which isn’t otherwise
possible through JavaScript. terms of correctness and trust. There are varied certificate-
status verification mechanisms, including CRLs and

computer.org/ITPro 47
 FEATURE: SECURITy
OCSP. Similarly, there are multiple certificate-chain-
building algorithms, such as PKIX. Depending on the
available PKI services and configuration, the certificate
validator component uses an appropriate certificatechain-
building algorithm and certificate-status verification
mechanisms to validate the target certificate.
Typically, there are multiple trusted certification
authorities in a given business context, so it’s critical to
maintain a central repository of all related certificates and
CRLs. These certificates are stored either in a database,
local file system, or directory. The certificate validator
component retrieves certificates from the underlying
repository and validates their status.
Signature Storage and Archival
This component addresses nonrepudiation. The signature
and transaction data must be stored and archived securely
for smooth retrieval in case of disputes. Signatures will be
stored with transaction data or in isolated central storage
with cross references to transaction data.
Typically, digital signatures are stored for a longer
duration as a proof of nonrepudiation, so a secure archival
mechanism separate from the active signature storage
space offers optimal performance. This component is also
responsible for periodically archiving certificates and
CRLs critical for supporting nonrepudiation.
Offline Signature Verification Utilities
These are the tools used in case of an audit or
nonrepudiation trial. They retrieve the signature from
active or archival storage, validate signatures, and prove
the signature status by referring to the signed date and
time. To address a scenario in which the certificate status
is invalid at the time of the audit but valid when the
signature was created, it’s important to include a time
stamp as part of the signed content.
Certificate and CRL Update Utilities
The list of trusted certification authorities can
also change depending on business needs. This
requires the administrator to update the certificate
and CRL repository accordingly. Certificates will
have a limited shelf life and will need to be
updated occasionally; however, CRLs will be
issued at regular intervals. The administrator
must download the latest CRLs and certificates
from the trusted sites and update the repository.
Automated scripts and tools that download CRLs
using preconfiguration criteria and update local
certificate store are productive.
Certificate & CRL Repository This
component is mainly responsible for organized
storage of certificates and CRLs, which are
required for successful certificate status
48 IT Pro March/April 2013
validation. Certificates and CRLs can be stored in
multiple storage places, including file systems
and directories. This component abstracts the
underlying storage details and provides a
consistent interface to access and manage
certificates and CRLs.
Secure Private Key Storage
The security of the entire system depends on the
security of underlying private keys. The private
keys can be stored as files either in local software
file system or on hardware, such as smartcards
for higher security. There are multiple key
storage formats, such as PKCS#11 (hardware
crypto interface), PKCS#12, and JKS. This
component abstracts the details of underlying
private key storage and format. It provides a
consistent interface to access and manage private
keys securely for signing.
Security Assurance
When implementing this digital signature
framework, developers should follow
application- security best practices prescribed for
JavaScript, Java applets, and general Web
applications (see www.owasp.org and
https://buildsecurityin. us-
cert.gov/bsi/home.html). Insecure software
implementation practices can increase the attack
surface and expose the applications to potentially
dangerous vulnerabilities, such as cross-site
scripting or malware introduction, and undermine
the system’s usefulness. A detailed discussion on
application security threats in Web applications is
out of scope for this article.
Digital Signature Extensions to HTML
If the HTML specification is amended to define
ways in which browsers support digitally signed
Web content, it will become easy to build Web
applications with digital signature support in a
browser- and system-agnostic manner.
Considering HTML’s wide applications and the
complexities of such a huge specification,
amending it won’t be trivial. However, we have
some ideas.
First of all, the revised specification should
define a new attribute “sign” to be supported by
all significant HTML elements (for example,
form fields such as form, text, text area, lists,
and hidden fields) that indicate whether the field
should be part of the signed content. Introducing
this optional attribute would let developers
select which content to sign. For example,
 <input type="text" name="OrderNumber"
value="" sign>
<textarea name="Comments" rows="10"
cols="10">
Here, the data in the “OrderNumber” text field
would be digitally signed but not the data
entered in the “Comments” text area.
Second, the specification should extend
“sign” attribute support for forms with file
uploads, so that the file content can be digitally
signed.
Third, the specification should define a set of
new attributes for the “Form” field that define
how the signatures should be handled for form
content. For example,
<form name="OrderForm" action-
"actionURL" method="post"
signattrbs="format=pkcs7,
encoding=base64,showTBSData=true,
promptForCertificate=true,trustedCAs=
'issuer dns of trusted certificates',
signatureAlgo=RSAwithSHA1,
includeCertChain=true">
In this example, signattrbs defines the browser’s
signature component behavior:
• format specifies the signature standard (PKCS#7);
• encoding reveals the digital signature’s encoding format
(for example, Distinguished Encoding Rules 15 or
Base6416 encoding);
• showTBSData, if true, displays the content being signed
so the user is aware of what’s being signed;
• promptForCertificate, if true, tells the browser to prompt
the user to select the certificate to be used for signing
among those available for that browser;
• trustedCAs provides Issuer Distinguished Name
attributes of the trusted certificate authority (CA)
certificates—the user can select certificates only from
this list of CAs; and
• includeCertChain tells the browser to include or exclude
the certificate chain.
The specification can also standardize support for
browsers’ software and hardware-based key store types.
D
igital signatures can help build more secure and
efficient Web applications across business
segments. Wider adop-
tion of digital signatures would be possible if the HTML
standard specification were extended to provide integral
support to digital signatures while defining tags that can
trigger digital signature creation by browsers. By
standardizing this feature for HTML, browser vendors can
provide their proprietary implementations supporting
digital signatures and developers can develop applications
as per single standardized HTML syntax in a browser-
agnostic manner.
In the absence of established standards to digitally sign
Web content, we’ve discussed a browser-agnostic
architecture for building digital signature support into Web
applications in a productive, flexible, and extensible
manner.
Acknowledgment
We thank Sudarshana Dhar for her editing support. Views presented
here are authors’ personal opinions and in no way represent the
opinion of Infosys.
References
1. HTML 4.01 Specification, World Wide Web Consortium (W3C)
specification, Dec. 1999; www.w3.org/ TR/html401.
2. Capicom Reference, Microsoft, 2012; http://msdn.
microsoft.com/en-us/library/aa375732(VS.85). aspx.
3. S. Mazumdar, “XML Digital Signature Tool,” Mozilla Add-Ons,
2012; https://addons.mozilla.org/en-Us/ thunderbird/addon/xml-
digital-signature-tool.
4. B. Kaliski, PKCS#7: Cryptographic Message Syntax, Version
1.5, RFC 2315, March 1998; ftp://ftp.rsasecurity.
com/pub/pkcs/ascii/pkcs-7.asc.
5. R. Housley, Cryptographic Message Syntax (CMS), RFC 3852,
July 2004; https://tools.ietf.org/html/rfc3852.
6. M. Bartle et al., XML Signature Syntax and Processing (Second
Edition), World Wide Web Consortium (W3C) recommendation,
June 2008; www.w3.org/TR/ xmldsig-core.
7. “Cryptography Objects,” Microsoft, 26 Oct. 2012;
http://msdn.microsoft.com/en-us/library/windows/
desktop/aa380254(v=vs.85).aspx#certificate_store_ objects.
8. “Java Cryptography Architecture—API Specification &
Reference,” Oracle, 25 July 2004; http://
docs.oracle.com/javase/1.5.0/docs/guide/security/
CryptoSpec.html.
9. PKCS#11: Cryptographic Token Interface Standard, RSA, 2004;
ftp://ftp.rsa.com/pub/pkcs/pkcs-11/v2-20/ pkcs-11v2-20.pdf.
10. PKCS#12: Personal Information Exchange Syntax Standard,
RSA, 1999; ftp://ftp.rsasecurity.com/pub/pkcs/ pkcs-12/pkcs-
12v1.doc.
11. “Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile,” tech. memo, The
Internet Society, 2002; www.ietf.org/rfc/ rfc3280.txt.
12. “The Online Certificate Status Protocol (OCSP),” The
Internet Society, 1999; www.ietf.org/rfc/rfc2560.txt.
13. “HTML Signing Profile,” World Wide Web Consortium
(W3C), Feb. 2008; www.w3.org/2007/11/h6n.
14. “Java PKI API Programmer’s Guide,” Oracle, 1993;
http://download.oracle.com/javase/6/docs/technotes/
guides/security/certpath/CertPathProgGuide.html.
computer.org/ITPro 49
 FEATURE: SECURITy
15. Data Networks and Open System Communications, Int’l
Telecommunication Union recommendation, 2002;
www.itu.int/ITU-T/studygroups/com17/
languages/X.690-0207.pdf.
16. “The Base16, Base32, and Base64 Data Encodings,”
tech. memo, The Internet Society, 2006; http://tools.
ietf.org/html/rfc4648.
Harigopal Ponnapalli is a principal research
analyst at Infosys, India. His research interests
include strong authentication, PKI, security
assurance, and software piracy. Ponnapalli received
his M.Tech in automation and computer vision from
the Indian Institute of Technology, Kharagpur,
Internet Society, 1999; www.ietf.org/rfc/rfc2560.txt.
50 IT Pro March/April 2013
India. He is coauthor of Distributed Systems
Security: Issues, Processes and Solutions (Wiley,
2009). Contact him at
harigopal_ponnapalli@infosys.com.
Ashutosh Saxena is a principal research scientist at
Infosys, India. His research interests include
authentication technologies and key management.
Saxena received his PhD in computer science from
Devi Ahilya University, Indore, India. He is the
author of PKI—Concepts Design and Deployment
(Tata McGraw-Hill, 2004). He’s a senior member of
IEEE. Contact him at
ashutosh_saxena01@infosys.com.