This is old code not more maintained; see
This is the client side part of the j4sign usage example in a web
SimpleSignApplet is simple in the sense that refined
GUI features are avoided (like multiple threads used to correctly implement
the progress bar), in favor to a clear exposition of specific signature
The goal was to illustrate an approach in which the client side
encryption, involving cryptographic token management via JNI, is completely
separated from server side CMS message building. This lightens the applet,
which has not to bear the weight of the BouncyCastle classes.
Note that in actual implementation of
digesting is done on the server, and encapsulated in a digestInfo. Only digestInfo
is sent to the applet.
Another feature is the encapsulation of the JNI part (the excellent pkcs11
wrapper developed by IAIK of Graz University of Technology, and the pcsc
wrapper taken from Open Card Framework project), along with the corresponding
native libraries, in a standard Java Extension, named
and Deploying Java Extensions.
The extension is deployed automatically the first time the applet is loaded.
The ultimate dependency for the applet is the cryptoki library, which has to
be provided from the PKCS11 token manufacturer. The
PCSCHelper class uses the pcsc wrapper
trying to infer the correct library from the ATR string returned from the
Some words about security; all downloaded jars, including the
SmartCardAccess extension, has to be signed in order to work;
this is needed for tho reasons:
- the applet loads native libraries
- the applet deploys a java extension.
This gives more confidence about signing software integrity.
The entire example, with the
CMSServlet server side counterpart,
is designed to permit the use of the standard JDK tools. The applet can be
executed with applet viewer tool (no HttpSession in the servlet, nor HTML
forms on the client side are used).
This eases the use of an IDE for test and debugging; we use, and recommend,
the Eclipse) IDE.
N.B.: IN A REAL WORLD WEB APPLICATION SCENARIO, YOU CAN (AND SHOULD) TAKE
ADVANTAGE OF THE FULL SERVLET API, AND HTTP/HTML FEATURES.
Here are the
SimpleSignApplet operations in detail; the applet
talks with the server (servlet) in HTTP:
- The applet initialization method (init()) builds the GUI layout: a text
area in the center, and, in the bottom, a button to load data from server and
a password field.
A detailed log is shown on System out (Java Plugin console).
- When the "Load data" button is pressed, the non repudiation certificate is
searched on the PKCS11 token. If such certificate is found a GET request is generated,
retrieve parameter with value
the server returns the message to sign.
Immediately after, another GET request is sent, specifiying a
retrieve parameter with value
ENCODED_AUTHENTICATED_ATTRIBUTES, and a
with the certificate as value; the server calculates (using also the certificate)
the Authenticated Attributes data, SHA-256 digests and encapsulates them in a digestInfo.
The digestInfo is returned to the applet.
The message and a textual representation of the authenticated attributes are
presented in the text area.
Note that authenticated attributes includes a timestamp, then even if the
message is the same, the digestInfo to encrypt change every time the
user loads the data from server.
- When the user insert the password in the field and press return, the
signing process starts:
- the PCSC layer is invoked to query for an inserted token, and if one is
found the relative PKCS#11 cryptoki is (hopefully) detected and loaded.
- Then the token is checked for the required signature algorithm
(RSA_PKCS), and queried for a suitable (non repudiation) certificate - private key pair.
- Then the digestInfo is sent to the token for the encryption procedure.
- The signature is sent to the server via HTTP POST, along with the signer
certificate extracted from the token (The same that was already sent before).
- The server acknowledges confirming signature verification and CMS
building and saving.
N.B. note that in this example signature verification only ensures
integrity; a complete verification to ensure non-repudiation requires
checking the full certification path including the CA root certificate, and
CRL verification on the CA side. (Good stuff for a next release ...)