Now, let’s get into the smart card business, with a first session about mobile payment.
Internet banking is amazingly common in Korea. 63M subscribers in 2010, and 66% of inquiries, and 33% of deposits and withdrawals. 7% of that is mobile. On PCs, most banks use an ActiveX plug-in, which provides an easy interface to deply certificates and run the SEED algorithm. However, this requires Internet Explorer, and ActiveX is sensitive to many vulnerabilities.
In the Korean case, SSL is used, but they don’t simply use it to authenticate the server, as they also require client authentication. This means that a private key needs tobe stored on the client, and that some cryptographic computations need to occur.
So, the question is: how to get a standard solution on mobiles, which would also offer a high level of security. On mobiles, ActiveX doesn’t work, all applications are proprietary, and they run into typical issues: different solutions on differnt kinds of mobiles, and a lot of complexity, with security issues.
Browsers could have been a solution, but there are interoperability issues between mobile browsers, and SSL client authentication is not fully supported on most platforms. For instance, on Android, it is not possible to enroll a user certificate. Finally, although all mobiles include a SIM card, mobile browsers don’t take advantage of the SIM card to store the SSL client secrets and perform crypto computations.
So, the solution is to use Java ME with JSR-177 and JSR-290. Here, they are using the PKCS#11 part of JSR-177 (SATSA-PKI package), which is based on the OMA WIM specification. JSR-290 is used to load and render HTML documents, to manipulate content of the document, and to control the execution of scripts.
JSR290 includes OpenSSL, which provides a way to support additional crypto engines. JSR177 is used to implement the RSA_Sign() method and the ENGINE_load_private_key() through JSR177 instead of performing them on the device. CHAPI is used as glue there, but I didn’t really get it. There is code on the slides, so I may get a second chance later.
This is actually a nice use case, with some originality when compared to the trivial SATSA-APDU examples. The only question is: why is this thing not standard on devices that support both JSR-290 and JSR-177? Something to think about for MSA-Next.
No Comments