Digital Signature Smartcard Cryptographic
Authentication Security Software
A project from Italy that is devoted to providing a simple software layer for digital
signatures when an hardware cryptographic token, such as a smartcard, is required.
The main goal is to maintain platform independence and application environment neutrality (web and standalone usage examples
are provided). The default implementation tries to comply as strictly as possible with the
Italian legal digital signature directives.
j4sign is developed at Servizio Sistema Informativo in the Municipality of Trento, and is currently used to provide services
involving digital signature of electronic documents.
The project core is implemented in the Java language, and is essentially an extension of the open source BouncyCastle cryptographic libraries for using PKCS#11
tokens.
PKCS stands for Public Key Cryptographic Standards which is a set of specifications proposed by RSA Security Inc. Many of them has become RFCs or are de-facto standards.
PKCS#11, for example, is the most widely used API for interacting with cryptographic tokens, because it was the first adopted
in web browsers. For more
information about PKCS standards go to the RSA Labs
website.
Since the PKCS#11 standard is an API specification in the C programming language, implementations provided by token manufacturers
are typically native libraries. The project uses Java Native Interface and related native libraries to interact with tokens.
For PKCS11 they use the excellent pkcs11 wrapper
developed by IAIK of Graz University of
Technology, released under an Apache/BSD-style license.
For basic SmartCard detection they also use the PCSC wrapper developed by the Open Card
Framework
consortium; this wrapper (the wrapper only) also is released under Apache/BSD-style license.
The project addresses the Windows OS initially, due to the prevalent availability of pkcs11 implementation libraries for this
platform; extension to GNU Linux OS is scheduled for
future releases.
j4sign has the goal of becoming the first Java2 free software implementation of an
"Italian law - compliant" digital signature. Other similar software exists, see SmartSign and OpenSignature projects, but they use primarily C, C++ language.
The first release offers:
Note that in the included examples of signature verification only ensures signed data
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.
Smart Sign Project
This project provides software suitable for smartcard based digital signature and both local and remote authentication
security services. It can also be used to integrate smart card technology into a working Certification Authority that issues
public key certificates for the users through the web.
For example, they provide a module that is known to work with the OpenCA Certification Authority for on-board keypair generation.
Their software works with different kinds of smart cards including modules that work with Schlumberger Cyberflex Access 16K
and Cryptoflex 16K smart cards and any Java Card 2.1.1 compliant smart card (i.e. both Schlumberger Cyberflex Access 32K and
Gemplus GemXpresso
211/PK).
The software has been developed and tested with Towitoko's CHIPDRIVE and Schlumberger's Reflex 72 card readers. It is known to
work fine with Gemplus GCR410, GCR400FD, GemPC and Microsystem's SCM readers too.
Features
* automatic storing of private key and public certificate on the smartcard during the interaction with OpenCA for the
"certification process"
* use of smartcard to sign e-mail and e-news from within Netscape Messenger
* use of smartcard to sign/verify every kind of file with a simple shell command
* smartcard-based authentication of local users to a system by means of a public key authentication protocol
* smartcard-based authentication of remote users to a system by means of a smart card enabled OpenSSH
* interactive command line browsing and invoking of all supported card commands for Cyberflex cards (ISO 7816 compliant and
not)
Download Smart Sign
Software and other required components.
Cert validation (CRLs or OCSP) is used during authentication, not authorization. SSL authentication, such as to AKO or the AF Portal,
involves an exchange of certificates, trustpoint chaining, cert validation, *and* an exchange of private key proofs (otherwise anyone in
possession of your certificate can authenticate as you).
Once authenticated, apps are pretty much free to make authZ decisions as they see fit. Most use the subject alternative names in the certs (such
as the AD UPN to map the user's cert to a local authZ store, but I also know of applications that use the public key itself.
Technically speaking, the card is immaterial to this process. While DoD PKI certs loaded on CACs include an OID indicating that the keys were
issued on a hardware token, no known applications process this OID; most COTS products aren't that
flexible. So a software key pair with the right certificate profile can also be used. However, the DoD is pretty strict about profiles usage in
software certs.
