Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Wireless security1 Data security in mobile Java applications - how to select and use third-party security toolkits Independent Study: Wireless Security."— Presentation transcript:

1 Wireless security1 Data security in mobile Java applications - how to select and use third-party security toolkits Independent Study: Wireless Security Weiyang Zhang March 20, 2003

2 Wireless security2 Table of Contents Introduction Content-based security Distributed access control Device security Lightweight mobile cryptography toolkits Examples

3 Wireless security3 Introduction 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.

4 Wireless security4 Content-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.

5 Wireless security5 Problems of Content-based security(1) Direct connection between client and server must be established

6 Wireless security6 Problems of Content-based 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.

7 Wireless security7 Problems of Content-based security (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.

8 Wireless security8 Distributed Access control(1) single sign-on services

9 Wireless security9 Distributed Access control(2) Federation single sign on domain

10 Wireless security10 Device 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.

11 Wireless security11 Lightweight mobile cryptography toolkits - 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

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

13 Wireless security13 Bouncy 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.

14 Wireless security14 Bouncy 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.

15 Wireless security15 Bouncy 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.

16 Wireless security16 Phaos Technology Micro Foundation 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.

17 Wireless security17 Phaos 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.

18 Wireless security18 NTRU 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.

19 Wireless security19 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.

20 Wireless security20 B3 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.

21 Wireless security21 B3 security advantages Speed Seamless integration with existing enterprise authentication infrastructure Strong two-factor authentication Tamper detection

22 Wireless security22 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.

23 Wireless security23 Digital signature examples(2) 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.

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

25 Wireless security25 Digital signature examples(4) 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(); }


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

Similar presentations


Ads by Google