1 / 25

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

Data security in mobile Java applications - how to select and use third-party security toolkits . Independent Study: Wireless Security Weiyang Zhang March 20, 2003. Table of Contents. Introduction Content-based security Distributed access control Device security

omana
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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. Wireless security

  4. 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. Wireless security

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

  6. 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. Wireless security

  7. 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. Wireless security

  8. Distributed Access control(1) • single sign-on services Wireless security

  9. Distributed Access control(2) • Federation single sign on domain Wireless security

  10. 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. Wireless security

  11. 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 Wireless security

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

  13. 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. Wireless security

  14. 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. Wireless security

  15. 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. Wireless security

  16. 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. Wireless security

  17. 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. Wireless security

  18. 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. Wireless security

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

  20. 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. Wireless security

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

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

  23. 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. Wireless security

  24. 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. Wireless security

  25. 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();} Wireless security

More Related