4Investigations on CyberVote client security issues |
|
4 INVESTIGATIONS ON CYBERVOTE CLIENT SECURITY ISSUES |
Electronic software distribution over any network or physical delivery using floppy disk or a CD-ROM involves potential security problems. CyberVote has to make sure that the delivered code reaches the voter without any modification during delivery. The CyberVote also has to make sure that the voter is confident that the code he/she receives is from authentic election server and it is not tampered. These issues are addressed using code signing methods discussed in section 4.1.
The CyberVote client requires cryptographic computations to carry out the voting protocol and some of the authentication and integrity protection functions on voter data as well as voting data. If Java is used as a programming language for CyberVote client, CyberVote has to make sure that all the necessary cryptographic functions are loaded for the client. Section 4.3 describes cryptography support needed for client software and how to make sure that these classes are loaded for the client software.
4.1 Authenticity and integrity of client side software |
|
Code signing method is used to maintain integrity and authenticity of the code being delivered to the voter. A private signing key is used to sign the code. A Certificate Authority (CA) is a trusted company that issues certificates attesting a binding between a digital ID and one or more public keys. Once the voter receives the code he/she can verify the signature using a certificate issued by a CA whom he/she trusts to confirm integrity and authenticity. That is, code signing allows voters to confirm the following issues:
· Identity of code signer: Signed code includes digital signature that allows voters to identify the signer (developer or election authority).
· No unauthorized modification of code: The digital signature allows voters to determine whether someone other than the signer has modified the code.
Code signing needs maintaining of valid certificates by CyberVote. There are two possibilities:
· Operate a CyberVote CA and issue certificates for different elections (requires installing a CA key in the client).
· CyberVote purchases a valid intermediate CA-certificate from a well known (recognized by the browsers) CA and then use such a CA-certificate to issue new certificates for the elections.
The delivered voting software to a voter from CyberVote may be:
· A Java applet which voter downloads using a browser from election server and runs it inside the browser, or
· An application that is delivered to voter in a legitimate manner. Voter installs it in his device and runs it for the voting related activities.
In the following sections we see the code signing techniques for Java applets and applications.
4.1.1 Code signing of Java Applet
Java applets are contained in a sandbox by default for security reasons. That is, generally applets are not allowed to use some capabilities that might be dangerous to the user’s machine. These capabilities include reading or writing to hard disk, connecting to some arbitrary machine in the network, reading some system parameters, or popping up arbitrary message windows. However, newer browsers allow applets to do any or all of the above things if the applet is signed with a digital ID, which the user trusts. When a signed applet requests any of the special capabilities, browser pops up a window with the attached certificate and asks the user to either grant or deny the permission relating the capabilities. However, if the applet is not requesting any special permission, it is allowed to run within the sandbox irrespective of whether it is signed or not. This might change in the newer versions of the browsers (e.g., Netscape 6, see below) where if the applet is signed, irrespective of whether it is requesting a special capability or not, browser will pop up a security dialogue box.
The browser carries out the certificate verification part where the voters don’t have to know how cryptography works or where the certificates are stored. The installed standard off-the-shelf browser at the client side is assumed to be an authentic version. A number of CA public keys are pre-installed in the browser and these keys are trusted to act as roots for certificate verification. Hence, if the browser displays a pop-up window about the certificate, it can be assumed that the certificate verification is done in a legitimate way.
Browsers that don’t pop up any security dialogue when a signed applet is encountered wait for a dangerous capability request before they pop up such a security dialogue box. If the CyberVote client does not request any of the threatening capabilities at the user machine (the current version does not), then a question arises: how to make sure that the voter is confident that the applet downloaded is signed. This situation requires that a browser pop up a security dialogue box whenever it encounters a signed applet as in the case of Netscape version 6 or higher.
Netscape and Microsoft Internet Explorer have different approaches in granting extra privileges to applets and the signing procedures are different, too.
http://www.suitable.com/Doc_CodeSigning.shtml gives step-by-step instructions on how to sign Java applets for these browsers. In the following subsections we note few points on these steps and provide further links for elaborate description.
4.1.1.1 Netscape Browsers
In Netscape 4 an applet must call into the netscape.security package to enable a privilege, even if the applet is signed. If it does not, it will be treated as unreliable. Thus applet signing and granting of privileges are treated separately.
In Netscape 6, signed applets are directly supported by the Java plug-in. When the browser encounters a signed applet, a security dialog is automatically popped up. The applet does not have to call any method to enable privileges; privileges are already enabled.
In the case of Netscape 6, two mechanisms may be used for applet signing:
· JAR signing in the JDK through an RSA certificate
· Netscape Object Signing
4.1.1.1.1 JAR Signing with the JDK
Following site gives very good information on how to achieve signing through RSA certificate:
http://java.sun.com/products/plugin/1.3/docs/rsa_signing.html.
Here we list simple steps of doing the signing. We assume that JDK 1.3 is installed and the tools jarsigner and keytool that are part of JDK are in the execution PATH. Following are Unix commands, however with proper changes, these could be used in Windows as well.
1. First generate a key pair for our Certificate:
keytool -genkey -keyalg rsa -alias AppletCert
2. Generate a certification-signing request.
keytool -certreq -alias AppletCert > CertReq.pem
3. Send this CertReq.pem to VeriSign/Thawte webform. Let the signed reply from them be SignedCert.pem.
4. Import the chain into keystore:
keytool -import -alias AppletCert -file SignedCert.pem
5. Sign the CyberVote archive “TeleVote.jar”:
jarsigner TeleVote.jar AppletCert
This signed applet TeleVote.jar can now be made available to the web server. For testing purpose we can have our own test root CA. Following are the steps to generate a root CA by using openssl.
1. Generate a key pair for root CA:
openssl genrsa -des3 -out CyberVoteCA.key 1024
2. Generate an x509 certificate using the above keypair:
openssl req -new -x509 -days 365 -key CyberVoteCA.key -out CyberVoteCA.crt
3. Import the Certificate to keystore.
keytool -import -alias CyberVoteRoot -file CyberVoteCA.crt
Now, in the step 3 of jar signing above, instead of sending the request certificate to VeriSign/Thawte webform for signing, we can sign using our newly created root CA using this command:
openssl x509 -req -CA CyberVoteCA.crt -CAkey CyberVoteCA.key -days 365 -in CertReq.pem -out SignedCert.pem –Cacreateserial
However, our test root CA has to be imported to the keystore of voter’s web browser in some way. [This was not investigated. We used some manual importing procedure which is not recommended way]
More information on jarsign, jar and keytool can be found in http://java.sun.com website. And more information on openssl can be found http://www.openssl.org.
4.1.1.1.2 Netscape Object Signing
Following site gives detailed information on Netscape object signing:
http://developer.netscape.com/docs/manuals/signedobj/trust/owp.htm
This method was used in previous versions of Netscape (i.e., older to version 6) with its own security model. The Object Signing Tools could be used to sign a Java applet so that it could be executed in the JVM. Netscape also provides a set of Java classes, netscape.security, that is used by the applet to enable security in the browser. Such signed applets for Netscape 4 will continue to work in Netscape 6; a stub class for the netscape.security package has been included. The stub class does nothing other than allow the applet to load into Java plug-in as though it were loading in Netscape 4. As said earlier, in Netscape 6, signed applets are directly supported by the Java plug-in.
To carry out Netscape object signing, one has to download and install Netscape signing tool available for many of the platforms from:
http://developer.netscape.com/software/signedobj/index.html
http://developer.netscape.com/software/tools/index.html?content=/software/signedobj/jarpack.html
The detailed information on this tool can be found at:
http://developer.netscape.com/docs/manuals/signedobj/signtool/index.htm
Some unsupported utilities that are useful for developers can be downloaded from Netscape at:
http://developer.netscape.com/software/tools/
Here we list simple steps to archive Netscape object signing. We assume that the installed signtool is in the execution PATH and CyberVoteDir is the top directory for CyberVote client software development and CyberVoteDir/lib contains the CyberVote client related class files and image files. We also assume CyberVoteDir/KeyDB is the directory, where the key database is stored (the files key3.db, cert7.db, secmodule.db).
1. We can print the list of certificates in the key database with
signtool -d"CyberVoteDir/KeyDB" –L
The certificates available for signing are indicated by a ‘*’ at the left of the certificate name. Let us assume AppletCert is CyberVote’s certificate for signing cybervote Java applet and this has * at its left. [For testing purpose, we can generate test certificates using signtool.]
2. Now, sign the files in the CyberVoteDir/lib and archive as a jar file named “TeleVote.jar”:
signtool -d" CyberVoteDir/KeyDB" -k"AppletCert" -p"password" -Z"TeleVote.jar" -c9 CyberVoteDir/lib
This TeleVote.jar can be verified to make sure everything went okay:
signtool -d" CyberVoteDir/KeyDB" –w TeleVote.jar
Now, this TeleVote.jar file can be made available from the web server to voters.
4.1.1.2 Internet Explorer
Usually, we don't have to modify the signed applet's code to work with Internet Explorer. However, if we need to do "dangerous" actions in one of five places: in the applets default constructor, init(), start(), stop() or destroy() methods, we have to use Microsoft's proprietary com.ms.security classes.
Step-by-step instructions are provided at:
http://www.suitable.com/Doc_CodeSigning.shtml
Tools necessary for signing applets can be downloaded from Microsoft site:
http://www.microsoft.com/java/download.htm
When we tested the applet signing for IE 6.0 with the Microsoft tools. It worked the same way as in Netscape 6.0. When the signed applet is loaded a pop up window presents the certificate and asks permission to run. The main difference in the signing is that Microsoft wants to use .cab files instead of .jar files. Otherwise the steps in the signing process were the same.
Figure 4. The security warning of signed applet by Internet Explorer.
Another problem with Microsoft and Internet Explorer is that Java support is discontinued. The IE 6.0 and Windows XP do not come with Java support. The IE 6.0 in our test worked because it was installed over previous 5.5 version.
4.1.1.3 Conclusion
Signing processes for different browsers can be done at once and at the same directory using a DOS batch file. The signed archives can then be served from a single html page; each browser will select the archive it understands.
4.1.2 Code signing of Application
The deliverable application has to be signed for the sake of checking integrity and authenticity of the application. Before installing the application in a mobile device or PC, voter has to check for the certificate and verify it for authenticity and then make sure that the received application is not tampered. In section 4.1.2.2.1, we see how to install an application in a Nokia 9210 securely.
Following are some of the tools and methods used for code signing.
4.1.2.1 Signing JAR Files
The Java Development Kit contains all the tools that are needed to sign JAR files. Depending on version of the Java Development Kit the program to use is:
· JDK 1.2 and higher versions, JAR Signing and Verification Tool or
· JDK 1.1 Java Security Tool (Javakey).
Here we have a closer look only of the latter because our Java code needs to be JDK 1.1 compatible.
The Javakey tool manages a database containing public/private key pairs and related certificates. In order to sign a JAR file with the Javakey tool, there needs to be a public/private key pair in Javakey's database. The Javakey tool will look for the database at the location specified by the identity.database property in the security properties file, java.security, located in the jre/lib/security directory of the JDK software. The database typically holds key pairs for many different potential signers, each key pair being associated with the username of a signer.
In addition to key pairs, Javakey's database contains certificates for the public keys. When a certificate is added to the database, Javakey assigns it a unique number for identification purposes.
To sign a file, Javakey needs several pieces of information:
· the username of the key pair to use,
· the number of the certificate to use,
· the name that the signature and signature block files are to have,
· the name that the signed JAR file is to have.
This information is provided by using a directive file, which is basically a property file that Javakey reads when signing a JAR file. Here's a sample directive file:
signer=CyberVote
cert=1
signature.file=sigfile
out.file=CyberVote.jar
JAR file is signed by using a command of this form:
javakey -gs directive-file jar-file
In this command:
-gs is the option that tells Javakey to sign a JAR file.
directive-file is the pathname of the directive file that Javakey should use.
jar-file is the pathname of the JAR file that is signed.
Javakey can perform many other functions related to managing the key/certificate database. For more information about Javakey, see the on-line JDK documentation at:
http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/javakey.html.
Using this instruction we managed to test singing a JAR file and no problems were encountered.
In JDK 1.2 and higher versions, the keytool, jar, jarsigner, and Policy Tool tools are available to facilitate various security-related operations. The keytool and jarsigner tools have already been described in the earlier subsection on code signing of Java applets. These tools replace javakey, which was an interim tool introduced in JDK 1.1. These new tools provide more features than javakey, including the ability to protect the keystore and private keys with passwords, and the ability to verify signed JAR files in addition to generating them. The new keystore architecture replaces the identity database that javakey created and managed. It is possible to import the information from an identity database into a keystore, via a keytool command. More information can be found at:
http://java.sun.com/products/jdk/1.2/docs/guide/security/SecurityToolsSummary.html
source:
http://developer.java.sun.com/developer/Books/JAR/sign/signing.html
4.1.2.2 Secure Application installation
The web browsers in the current mobile devices have limited capabilities. This means that by just browsing a CyberVote server from a mobile device and voting from it may not be possible. Hence, if CyberVote voting from a mobile device has to be realized, it is possible by bundling the CyberVote client in an application form and installing it in the mobile device. Then at the time of an election, by running this application a voter can vote from the mobile device. This process might have some potential security holes. Secure installation of voting client to the mobile device is the concern of this section. In the first subsection, we see how CyberVote can make it possible to install a CyberVote client in a voter’s 9210 with more confidence in the installed application. In the second subsection, we see how to make sure that needed Java specific security classes are loaded for a CyberVote client in mobile device.
4.1.2.2.1 Secure Application Installation to Nokia 9210
First we need to create public key and certificate. This is done via makekeys program. For some reason it is not part of the Symbian’s Java SDK, but it has to be separately copied from C++ SDK in the Symbian CD to the hard disk.
The instructions to create the key and certificate from the Symbian SDK documentation file:
Symbian\6.0\Shared\DeveloperLibrary\Crystal6.0Java\Common\ToolsAndUtilities\Installing\HowToMakekeys.guide.html
If a trusted certificate is needed, a request file to a CA can be made using the same makekeys program. Instructions are in file:
Symbian\6.0\Shared\DeveloperLibrary\Crystal6.0Java\Common\ToolsAndUtilities\Installing\HowToMakekeysReq.guide.html
The certificate request should then be sent to the CA, who will verify your identity and then return an authenticated digital certificate. This phase can be skipped in the development phase by using just self-generated certificate. This signed certificate is used in the making of application installation file (see below 9210 Application installation). When the application is being installed in 9210, it displays a security dialogue mentioning the authenticity of the application. Then voter will continue with the installation if it is authentic.
4.1.2.2.2 PC platforms and Compaq iPAQ
Current version of CyberVote mock-up system provides java applets as CyberVote client for PC users. Signing of java applets covered in 4.1.1. In the future, if the CyberVote client is provided as an application rather as an applet for PC users, proper code signing methodologies should be used. Following link explains such methods for much of the Microsoft applications.
These methods also can very well be used for installing applications for windows CE platforms. For example, in iPAQ case, an installation file in .cab file format could be prepared and then signed with Microsoft Authenticode [as per the instructions in the above link]. User checks the certificate for integrity and authenticity, before installing CyberVote client into his/her iPAQ.
4.1.2.3 Conclusion
Code signing of applications ensures integrity and authenticity of the code. In case the application is provided as a java file, jar-signing methods can be used for signing applications. If the application is to be installed in mobile clients, then appropriate code signing methodologies have to be accounted depending on the mobile client platforms. We described two such methods for Nokia 9210 and Compaq iPAQ for the mock-up and investigated one method (for Nokia 9210) in greater detail.
4.2 Authenticity and Integrity of Election Parameters |
|
The same CyberVote client software could be used for different elections and whenever necessary the software could be upgraded. In that case the election parameters form a distinguishing factor. Election authority sets the values for these election parameters. There is a need to ensure the integrity and authenticity of such parameters, even if the client software is proven legitimate. How to do this depends on how the client software is maintained. If the client software is a Java applet, we could combine the parameters along with the code before signing the code.
We need to support the mobile devices, which may not have powerful web browser. This might mandate that the client software is an application. Even for the PCs also, we could provide CyberVote client software as an application. Once the application is installed, all the subsequent parameters downloaded from an election server for a particular voting must be signed. Election authority could be the signer in this case. With this signature, authenticity and integrity of the downloaded parameters are confirmed when the certificate is verified and integrity checking is done at the client side. This process involves software programming inside the code base, unlike the above code signing procedures that involve working outside the code base. Present code base is an applet version (modified to work as an application, but still there are few issues to be fixed) and parameters are presented to the applet from the serving html page. Hence, verifying of parameters is not present as part of the code base yet.
Another possibility is that we have a special application, which downloads the jar file and runs it for each election. This special application could be something similar to Java web start (see the link below), or the Java web start itself.
http://java.sun.com/products/javawebstart/
In this case again, parameters could be integrated with the jar file.
Integrating parameters with jar file means one signing process and the election authority is the preferred signer. If the parameters are isolated from client software, then the client software could be signed by CyberVote (S/W developer) and the parameters could be signed by election authority.
4.3 Cryptography Support in Client Platforms |
|
The JDK Security API is a core API of the Java programming language, built around the java.security package (and its subpackages). The first release of JDK Security introduced the "Java Cryptography Architecture" (JCA), which refers to a framework for accessing and developing cryptographic functionality for the Java platform. In JDK 1.1, the JCA included APIs for digital signatures and message digests.
JDK 1.2 significantly extends the Java Cryptography Architecture. It also upgrades the certificate management infrastructure to support X.509 v3 certificates, and introduces a new Java Security Architecture for configurable, flexible, and extensible access control. Unfortunately the CyberVote client must be PersonalJava compatible and thus JDK1.2 cannot be used.
4.3.1.1 Security Providers
The Java Cryptography Architecture introduces the notion of a Cryptography Package Provider ("provider" for short). This term refers to a package (or a set of packages) that supply a concrete implementation of a subset of the cryptography aspects of the Java Security API. A provider may, for example, contain an implementation of the Digital Signature Algorithm (DSA) and/or the RSA Cryptosystem (RSA). A program may simply request a particular type of object (such as a Signature object) implementing a particular algorithm (such as DSA) and get an implementation from one of the installed providers. Alternatively, the program can request a specific provider. (Each provider has a name used to refer to it.)
JDK 1.1 comes standard with a default provider, named "SUN". The "SUN" provider package includes:
· An implementation of the Digital Signature Algorithm (NIST FIPS 186).
· An implementation of the MD5 (RFC 1321) and SHA-1 (NIST FIPS 180-1) message digest algorithms.
Each JDK installation has one or more provider packages installed. New providers may be added statically or dynamically. The Java Cryptography Architecture offers a set of APIs that allow users to query which providers are installed.
Clients may configure their runtime with different providers, and specify a preference order for each of them. The preference order is the order in which providers are searched for requested algorithms when no specific provider is requested.
For each engine class in the API, a particular implementation is requested and instantiated by calling a getInstance method on the engine class, specifying the name of the desired algorithm and, optionally, the name of the provider whose implementation is desired. If no provider is specified, getInstance searches the registered providers for an implementation of the named algorithm. In any given Java Virtual Machine (JVM), providers are installed in a given preference order. That order is the order in which they are searched when no specific provider is requested. If no installed provider implements desired algorithm, a NoSuchAlgorithmException is raised.
Provider Classes are installed by creating a "classes" directory in the JDK installation directory, and install the provider classes (the .class files) in that directory. For example, if the JDK is installed in a directory called jdk1.1.1, and the classes implementing the provider are in the COM.acme.provider package, install the classes in the directory jdk1.1.1/classes/COM/acme/provider. Alternatively, a zip or JAR (Java Archive) file containing the classes can be located anywhere on your CLASSPATH. The next step is to add the provider to list of approved providers. This is done statically by editing the java.security file in the lib/security directory of the JDK. Thus, if the JDK were installed in a directory called jdk1.1.1, the file would be jdk1.1.1/lib/security/java.security. One of the types of properties you can set in java.security is of the following form:
security.provider.n=masterClassName
Providers may also be registered dynamically. To do so, call either the addProvider or insertProviderAt method in the Security class. This type of registration is not persistent and can only be done by "trusted" programs.
4.3.1.2 The Important Classes
The MessageDigest class, which is used in current CyberVote mockup system (see section 2), is an engine class designed to provide the functionality of cryptographically secure message digests such as SHA-1 or MD5. A cryptographically secure message digest takes arbitrary-sized input (a byte array), and generates a fixed-size output, called a digest or hash. A digest has the following properties:
· It should be computationally infeasible to find two messages that hashed to the same value.
· The digest does not reveal anything about the input that was used to generate it.
Message digests are used to produce unique and reliable identifiers of data. They are sometimes called the "digital fingerprints" of data.
The Signature class is an engine class designed to provide the functionality of a cryptographic digital signature algorithm such as DSA or RSA with MD5. A cryptographically secure signature algorithm takes arbitrary-sized input and a private key and generates a relatively short (often fixed-size) string of bytes, called the signature, with the following properties:
· Given the public key corresponding to the private key used to generate the signature, it should be possible to verify the authenticity and integrity of the input.
· The signature and the public key do not reveal anything about the private key.
A Signature object can be used to sign data. It can also be used to verify whether or not an alleged signature is in fact the authentic signature of the data associated with it.
The KeyPair class is a simple holder for a key pair (a public key and a private key). It has two public methods, one for returning the private key, and the other for returning the public key:
The KeyPairGenerator class is an engine class used to generate pairs of public and private keys. Key generation is an area that sometimes does not lend itself well to algorithm independence. For example, it is possible to generate a DSA key pair specifying key family parameters (p, q and g), while it is not possible to do so for an RSA key pair. That is, those parameters are applicable to DSA but not to RSA. There are therefore two ways to generate a key pair: in an algorithm-independent manner, and in an algorithm-specific manner. The only difference between the two is the initialisation of the object.
The Identity class is the basic key management entity. This class represents identities: real-world objects such as people, companies or organisations whose identities can be authenticated using their public keys. All Identity objects have a name and a public key. Names are immutable. Identities may also be scoped. That is, if an Identity is specified to have a particular scope, then the name and public key of the Identity are unique within that scope. An Identity also has a set of certificates (all certifying its own public key). Note: support for specific certificate formats such as X.509v3 is not available in JDK 1.1.
The SecureRandom class is intended to provide a software-based, platform independent, good-quality random number generator. There are two ways to instantiate a SecureRandom instance: either using the default seed mechanism or by providing a seed. Once the SecureRandom object has been seeded, it will produce bits as random as the original seeds.
sources:
http://java.sun.com/products/jdk/1.1/docs/guide/security/CryptoSpec.html
http://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.html
4.3.1.3 Java Cryptography Extension (JCE)
The Java Cryptography Extension (JCE) is a set of packages that provide a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers. The software also supports secure streams and sealed objects.
Sun's Javasoft cannot provide its international customers with an implementation of the JCE because of US export restrictions. However, there are other JCE implementations available.
In http://www.nue.et-inf.uni-siegen.de/SignStreams/csp/overview_provider.html there is a list of other JCE providers. Here we have a closer look at two of them.
4.3.1.3.1 The Bouncy Castle Crypto Package
The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms; it was developed by the Legion of the Bouncy Castle with help from several volunteers. The software with source code can be used freely even in commercial use. The package can be found at http://www.bouncycastle.org.
The package is organised so that it contains a light-weight API suitable for use in any environment (including J2ME) with the additional infrastructure to conform the algorithms to the JCE framework. The full API contains the JCE provider, clean room API, and the lightweight API.
Lightweight cryptographic API consisting of support for:
· BlockCipher,
· BufferedBlockCipher,
· AsymmetricBlockCipher,
· BufferedAsymmetricBlockCipher,
· StreamCipher,
· BufferedStreamCipher,
· KeyAgreement,
· Digest,
· Mac, and
· PBE.
The Bouncy Castle provider is a JCE compliant provider that is a wrapper built on top of the light-weight API. The advantage for writing application code that uses the provider interface to cryptographic algorithms is that the actual provider used can be selected at run time. This is valuable for applications that may wish to make use of a provider that has underlying hardware for cryptographic computation, or where an application may have been developed in an environment with cryptographic export controls.
Support for this JCE can be received through mailing list dev-crypto-subscribe@bouncycastle.org. This mailing list is for discussion of development of the package. It includes bugs, comments, and requests for enhancements, questions about use or operation.
The provider can be configured as part of Java environment via static registration by adding an entry to the java.security properties file. The line to be added is: security.provider.<n>=org.bouncycastle.jce.provider.BouncyCastleProvider
Where <n> is the preference of the provider (1 being the most preferred).
The Bouncy Castle provider will read X.509 certificates as per the examples in the java.security.cert.CertificateFactory class. They can be provided either in the normal MIME encoded format, or as DER binaries. In addition to the classes in the org.bouncycastle.ans1.x509 package for certificate generation a more JCE "friendly" class is provided in the package org.bouncycastle.jce. The JCE "friendly" class supports RSA, DSA, and EC-DSA.
The Bouncy Castle package has three implementation of a keystore. The first, Keystore.JKS is compatible with the JKS and the JDK keytool. The keystore is stored unencrypted on disk, with the keys encrypted with their own passwords. A SHA-1 HMAC is used to verify the keystore contents if a password is provided.
The second, Keystore.BouncyCastle, or Keystore.UBER will only work with the keytool if the password is provided on the command line, as the entire keystore is encrypted with a PBE based on SHA-1 and Twofish. PBEWithSHAAndTwofish-CBC. This makes the entire keystore resistant to tampering and inspection, and forces verification. The Sun JDK provided keytool will attempt to load a keystore even if no password is given, this is impossible for this version.
In the first two cases, the keys are encrypted with 3-Key-TripleDES. The third type of keystore is compatible with PKCS12.
4.3.1.3.2 Cryptix JCE
Cryptix JCE is a complete clean-room implementation of the official JCE 1.2 API as published by Sun. Cryptix JCE is expected to be 100% compatible with Sun's implementation and it is available internationally under liberal license.
Cryptix JCE currently supports:
· JDKs 1.1, 1.2 and 1.3
· Ciphers: Blowfish, CAST5, DES, IDEA, MARS, RC2, RC4, RC6, Rijndael, Serpent, SKIPJACK, Square, TripleDES, Twofish
· KeyAgreementsDiffie-Hellman
· Modes CBC, CFB-(8, 16, 24, ..., blocksize), ECB, OFB-(blocksize), openpgpCFB
· Hashes MD2, MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-0, SHA-1, SHA-256/384/512, Tiger
· MACs HMAC-MD2, HMAC-MD4, HMAC-MD5, HMAC-RIPEMD-128, HMAC-RIPEMD-160, HMAC-SHA-0, HMAC-SHA-1, HMAC-Tiger
· Signatures RawDSA, RSASSA-PKCS1, RSASSA-PSS
· Asymmetric ciphers RSA/PKCS#1, ElGamal/PKCS#1
· SecureRandom SPIs /dev/urandom on systems that support it (FreeBSD, Linux, OpenBSD and possibly other UNIXen)
The JCE is not completely finished and there is no documentation. A preliminary version is available in an archive, which contains the source and the .jar files. It is said to work on JDK 1.1.x, JDK 1.2.x (Java 2) and JDK 1.3.x. The home page of Cryptix JCE is http://www.cryptix.org/products/jce/.
4.3.1.4 Other Security Packages for Java
There are two other optional Java security packages available. They are not currently needed by CyberVote, but still it is good to remember their existence.
The Java Authentication and Authorization Service (JAAS) is a set of packages that enable services to authenticate and enforce access controls upon users. It implements a Java version of the standard Pluggable Authentication Module framework, and provides support for user-based, group-based, or role-based access controls.
The Java Secure Socket Extension (JSSE) is a set of packages that enable secure Internet communications. It implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol (such as HTTP, Telnet, NNTP, and FTP) over TCP/IP.
Source:
4.3.1.5 Java security support in small devices
The CyberVote test code did not run straight away in the Symbian's 9210 emulator, but it required only adding some Java classes and no change in the code. The added classes were java.security.* and sun.security.*, which we copied from JDK 1.1.8.
The 9210 device (at least with firmware v3.18) however does not work with these files either, but the code itself and also the added security classes need to be modified.
At present, PersonalJava is generally used in mobile devices (like 9210, iPAQ). The documentation for PersonalJava specifies that security package is optional. We experienced some problems in loading security classes in some of the PersonalJava implementations (PersonalJava in 9210 and Sun’s beta version of PersonalJava for mobile devices with ARM based processors). We wrote some cover classes for the security methods and will try to call the preinstalled security methods if they exist. If they don’t exist, it will load our own implementation of security methods. This work-around works with the PersonalJava implementations where we faced the problems in loading security methods. This has no side effect in Java applets if the above changes are incorporated in the CyberVote test codebase. However, if the future PersonalJava versions do not have such problems, then the mentioned work-around would no longer be necessary. In the future, many of the mobile devices are expected to support Java micro edition. Java Micro -edition security package issues are not yet clear to us.
There are several security packages available for Java, but unfortunately they are mostly optional in many Java environments or made by 3rd parties. Currently CyberVote requires only the basic JDK Security, which is widely supported but not in PersonalJava. However, because of the nature of Java, the missing packages or classes can be added to the client software package and the classes can even be modified. This is good news while ensuring that CyberVote system can be used in several computing environments.
If there is a need to use additional security and in future versions of CyberVote systems, there are APIs and packages classes readily available for many kinds of security and cryptography related programming.
4.4 Other general issues related to NOKIA 9210 |
|
In this section, we present some of the investigations carried out with regards to preparing and installing an application in a 9210. Most of the following instructions and notes may also apply (with a few changes) for application installation in a mobile device with Symbian operating system.
4.4.1 Application File Builder and Icon Designer
9210 SDK comes with an AIF Builder tool, which is an application that runs on development machine (not the device or Emulator). This helps in creating the required files for 9210-application. It works with all device families and programming languages.
A shell program is used to run an application in 9210. This program needs at least the following two files: an EPOC application file (.app), which, minimally contains a unique identifier (UID) to identify the program, and an application information file (.aif) to specify the application’s icon and caption.
Other files may also be required depending on the programming language: for example, for a Java application an additional text file (.txt) is required to specify the command line to the JVM when the application is launched, while for OPL, the OPL source file has to modified.
AIF Builder also allows one to launch the AIF Icon Designer program. This helps in creating the application's icon in the required EPOC specific bitmap file format, called the multi-bitmap file format (.mbm). The CyberVote specific icon can be created using this utility.
More information can be found from 9210 SDK documents at:
/Symbian/6.0/Shared/DeveloperLibrary/Crystal6.0Java/Common/ToolsAndUtilities/AIFUITools/AIFBuilderIntro/index.html#AIFBuilderIntro.toc
We used above methods for preparing a CyberVote Application installation file for 9210 as part of the mock-up work.
4.4.2 Application installation
Applications in 9210 are very well installed from a .sis file. This .sis file can be put in the CyberVote server or delivered to voter using a floppy or CDROM. The following paragraphs explain the creation of such .sis file.
First we need to make a .pkg file. Here is an example of the file where the files used in the emulator are packed into SIS file.
#{"TheVote application"},(0x01000009),1,0,0
*"CyberVote.key","CyberVote.cer"
; to install for CyberVote application
"\Symbian\6.0\NokiaJava_1.0\Epoc32\Wins\c\System\apps\TheVote\TheVote.jar"-"!:\system\apps\TheVote\TheVote.jar"
"\Symbian\6.0\NokiaJava_1.0\Epoc32\Wins\c\System\apps\TheVote\TheVote.app"-"!:\system\apps\TheVote\TheVote.app"
"\Symbian\6.0\NokiaJava_1.0\Epoc32\Wins\c\System\apps\TheVote\TheVote.aif"-"!:\system\apps\TheVote\TheVote.aif"
"\Symbian\6.0\NokiaJava_1.0\Epoc32\Wins\c\System\apps\TheVote\TheVote.txt"-"!:\system\apps\TheVote\TheVote.txt"
"\Symbian\6.0\NokiaJava_1.0\Epoc32\Wins\c\System\apps\TheVote\TheVote.mbm"-"!:\system\apps\TheVote\TheVote.mbm"
"\Symbian\6.0\NokiaJava_1.0\Epoc32\Wins\c\System\apps\TheVote\Surveys\matra\parameters.txt"-"!:\system\apps\TheVote\Surveys\matra\parameters.txt"
The .app, .txt, .aif and .mbm files are created with utility AIFbuilder as said in the previous subsection. For AIFbulider a logo bitmap, a unique identifier (in our example 0x01000009) and the command line parameters for the Java application are needed.
The .pkg file can be utilised also to install different files for different languages, but that has not been tested yet. The SIS file is then created with command:
makesis TheVote.pkg
The SIS file can then be installed to the device with PC Suite for Nokia 9210 Communicator software or the SIS file can be loaded from web with the web browser and installed with installation program found in the devices control panel.
4.5 Conclusion |
|
Ensuring integrity and authenticity of the application to users play major role in sensitive applications such as voting. Much of the security of voting process relies on the integrity and authenticity of the code being used for voting process. We have described some methods for ensuring the integrity and authenticity of the code being delivered to user either in java applet form or as an application for PC or mobile clients. We need certain security functions as part of the voting application. In java application or applet case, the java security classes are being used. We have investigated, how to make sure such classes are available when java CyberVote clients are used. As part of the mock-up work, we investigated on application in a Nokia 9210 mobile device.
