Wireless security1 Data security in mobile Java applications - how to select and use third-party security toolkits Independent Study: Wireless Security

Wireless security 1

Data security in mobile Java applicationsData security in mobile Java applications - - how to select and use third-party security toolkits how to select and use third-party security toolkits

Independent Study: Wireless SecurityWeiyang ZhangMarch 20, 2003

Wireless security 2

Table of ContentsTable of Contents

Introduction Content-based security Distributed access control Device security Lightweight mobile cryptography toolkits Examples

Wireless security 3

IntroductionIntroduction

The lack of data security on current mobile application platforms is one of the biggest hindrances to mobile commerce adoption, especially in the corporate world.

Even with mandatory HTTPS support in MIDP (Mobile Information Device Profile) 2.0, the standard J2ME platforms still cannot support versatile security solutions as those in the J2SE world.

Currently, to develop advanced mobile security solutions, we must rely on toolkits from third-party vendors. This article is talking about the toolkits from the Bouncy Castle open source community, Phaos Technology, NTRU, and B3 Security.

Wireless security 4

Content-based securityContent-based security

HTTPS, SSL, and TLS are connection-based security protocols.

The basic idea is to secure communication channels and hence, secure everything that passes through those channels.

Wireless security 5

Problems of Content-based Problems of Content-based security(1)security(1)

Direct connection between client and server must be established

Wireless security 6

Problems of Content-based Problems of Content-based security(2)security(2)

All content is encrypted. In some application scenarios, such as

broadcasting stock quotes or getting multilevel approval of a transaction, parts of the communication should be open. Yet we still want to verify the authenticity of those quotes and approval signatures. Connection-based security is no use here. Unnecessarily encrypting all content also introduces more processing overhead.

Wireless security 7

Problems of Content-based Problems of Content-based securitysecurity(3)(3)

HTTPS is inflexible for applications that have special security and performance requirements.

It lacks support for custom handshake or key exchange mechanisms. For example, HTTPS does not require clients to authenticate themselves. Another example is that any minor digital certificate-formatting problem causes the entire HTTPS handshake to fail. The developer has no way to specify what errors can be tolerated.

Wireless security 8

Distributed Access control(1)Distributed Access control(1)

single sign-on services

Wireless security 9

Distributed Access control(2)Distributed Access control(2)

Federation single sign on domain

Wireless security 10

Device securityDevice security

Mobile devices are easy to steal or lose. We must prevent nonauthorized personnel from accessing a device's sensitive data. For example, your company's financial data or private keys should not be recovered from a stolen mobile device. On-device information security is one of the most important challenges we face today.

HTTPS does not support on-device information security. Mobile clients are responsible for protecting their own data. Strong passwords usually protect on-device information.


Lightweight mobile cryptography Lightweight mobile cryptography toolkitstoolkits--General requirements(1)General requirements(1)

Fast Small footprint Comprehensive algorithm support cryptographic algorithms: 1. Symmetric key encryption 2. Public key encryption 3. Digital signatures 4. Password-based encryption


Lightweight mobile cryptography Lightweight mobile cryptography toolkitstoolkits--General requirements(2)General requirements(2) Sensible APIs Easy key identification and serialization Good reputation Timely bug fixes


Bouncy Castle lightweight APIBouncy Castle lightweight API

Bouncy Castle (BC) started out as a community effort to implement a free, clean-

room, open source JCE provider. The Bouncy Castle J2ME download package

contains the implementation of the BC lightweight API as well as two core Java classes not supported in J2ME/CLDC: java.math.BigInteger and

java.security.SercureRandom.


Bouncy Castle advantagesBouncy Castle advantages

When security holes or bugs are found, they are

fixed quickly. BC's flexible API design and community

development model allow anyone to contribute new algorithm implementations.

The BC community is constantly optimizing existing implementations.

Since BC implements an open source JCE provider, you can look at the BC JCE source code to figure out how to use the lightweight API for various tasks.


Bouncy Castle drawbacksBouncy Castle drawbacks

Many BC algorithm implementations come straight from textbooks.

The BC API design is flexible but quite complex, and beginners find it hard to learn.

The community support via mailing list often works well. But there is no guarantee that someone will answer your question, much less in your specified time frame.

To support so many algorithms, BC has a large footprint.


Phaos Technology Micro Phaos Technology Micro Foundation toolkitFoundation toolkit

Phaos Technology is a Java and XML security solution provider.

It offers toolkits for secure XML Java APIs, J2ME lightweight crypto APIs, and one of the first implementations of the SSL protocol on J2ME/CLDC.


Phaos Technology featuresPhaos Technology features

Phaos MF supports different algorithms: 1. Symmetric ciphers: AES, DES, RC2 and RC4 2. PKI ciphers and signature schemas: DSA,

RSA 3. PBES: PKCS #5, PKCS #12 Supports X.509 certificate parsing Supports ASN.1 encoding Supports efficient memory pooling Drawback: Phaos PBES implementation is too

heavy for small mobile devices.


NTRU Neo for Java toolkitNTRU Neo for Java toolkit

NTRU PKI algorithms include an encryption algorithm NTRUEncrypt and a signature algorithm NTRUSign, invented and developed by four math professors at Brown University.

NTRU provides an implementation of its algorithms in a Java package called NTRU Neo for Java.

The Neo for Java package runs on CLDC, CDC, and J2SE platforms. It has a memory footprint of 37 KB without signature key generation classes, which have a footprint of 35 KB.


B3 Security B3 Security

B3 Security is a San Jose, Calif. startup that specializes in developing new lightweight security infrastructures that minimize the current overhead associated with PKI.

Its flagship products are B3 Tamper Detection and Digital Signature (B3Sig) SDK and B3 End-to-End (B3E2E) Security SDK. Both are available for J2ME. The B3E2E SDK (still in beta) provides features equivalent to SSL in the PKI world, but with a shorter handshake, faster session key establishment, and less management overhead, especially for pushed messages.


B3 working procedureB3 working procedure

In its preferred operation mode, the B3Sig SDK uses two pairs of shared and nonshared secrets.

Nonshared secrets are used together with the message (or transaction) itself and user ID to generate a unique signing key for every message.

B3 algorithm then generates a digital signature containing three interrelated parts.

A B3 algorithm can verify message and user ID integrity with shared secrets.


B3 security advantagesB3 security advantages

Speed Seamless integration with existing enterprise

authentication infrastructure Strong two-factor authentication Tamper detection


Digital signature examples(1)Digital signature examples(1)

Digital signature can guarantee message integrity and authenticity in an open network. To generate a signature, you first calculate a hash (also called digest) of your message. Then you encrypt that hash with your private key to generate a signature.

The party at the receiving end first decrypts your signature into a hash using your public key. Then she calculates the hash from your message. If the two hashes match, the message is indeed from you and unaltered.



If someone altered the message during its transmission and generated a new hash based on the modified message, public key algorithms guarantee that he cannot produce a matching signature without knowing your private key. The two parties must share four pieces of information: the message itself, its digital signature, hash and signing algorithms, and the public key.



Bouncy Castle supports DSA, RSA, and ECC (Elliptic Curve Cryptography) digital signature algorithms. My code example only shows how to use the RSA signature.



Bouncy Castle RSA key generation in CryptoEngine:public void generateRSAKeyPair () throws Exception {

SecureRandom sr = new SecureRandom(); BigInteger pubExp = new BigInteger("10001", 16); RSAKeyGenerationParameters RSAKeyGenPara = new RSAKeyGenerationParameters(pubExp, sr, 1024, 80); RSAKeyPairGenerator RSAKeyPairGen = new RSAKeyPairGenerator(); RSAKeyPairGen.init(RSAKeyGenPara); AsymmetricCipherKeyPair keyPair = RSAKeyPairGen.generateKeyPair(); RSAprivKey = (RSAPrivateCrtKeyParameters) keyPair.getPrivate(); RSApubKey = (RSAKeyParameters) keyPair.getPublic();}

Documents

Wireless security1 Data security in mobile Java applications - how to select and use third-party security toolkits Independent Study: Wireless Security