Analysis and Conclusion
8.3 SCWS Implementation Issues
where time is of the essence2. The presented solution using SMS provides a pragmatic balance between security and usability.
In use case VW-2 there is minimal input from the mobile phone - it is used as a mere conduit for voting credentials, via a mobile application. It would be possible to employ an SCWS solution for storing and processing votes/voting credentials as in EV-1/EV-2. However, this would move the voting “ceremony” to the RW as the votes would then be input to the RW phone, rather than as an in-world voting activity.
Sending VCLs via the MNO network provides a second channel inaccessible from the VW, so protects against in-world attacks: placing sensitive vote processing in a TSL with a small attack surface, that is accessed using secure communication protocols (e.g.
HTTPs) introduces a trustworthy component to the proposal. Even if the VCLs are obtained from the potentially insecure mobile phone platform, knowledge fragmentation across four distinct zones means that they cannot be used to mount an attack without information from the other three zones, thus increasing the complexity of a potential attack. Again, a balance between security and usability is struck.
As Auth-2 was concerned with using depth cameras to create a dynamic biometric based on gesture recognition, the SCWS is not relevant. It may be possible in future to interface the authentication results from gesture recognition with the SCWS but this would need further research. Gesture recognition has the potential to become a flexible, non-intrusive, non-contact method for local authentication, with the advantage that a gesture is changeable in the case of compromise. In challenging environments this would provide a useful alternative authentication method, especially as dynamic biometry also improves unlinkability. The feasibility of match-on-card DTW processing of gestures captured using the Kinect/ Leap Motion devices was assessed: this could be performed on a phone using an HCE application [8]. In future, as 3D depth cameras become more widely available on mobile devices, the need for separate equipment to capture data will be removed, so this dynamic biometric authentication method could be used directly with phone sensors. However, research in this area is still at a very early stage.
8.3 SCWS Implementation Issues
Proof of concept versions for both the generic e-voting solution and the branchless banking application were produced in a simulated environment and successfully tested on a laptop computer (hosting an AMD processor 2.4GHz with 2GB of RAM and 512
2Instead of OTP tokens, providing SIMs with a SIM Toolkit m-payment application installed could be an alternative: again this would require a business relationship with the MNO, which may reduce the potential speed of deployment.
8.3. SCWS Implementation Issues 8. Analysis
Table 8.3: Security Requirements for Each Use Case
Security Req. EV-1 EV-2 MP-1 MP-2 Auth-1 Auth-2 VW-1 VW-2
Confidentiality Parta Xb X Partd X N/A X X
Integrity X ×c X Partd X N/A X X
Availability X X X X X N/A X X
Authentication X X X Partd X Parte X X
Non-Repudiation N/A N/A X X X N/A X N/A
aNot Coercion Resistant e-voting scheme
bRe-voting allowed as anti-coercion measure.
cNot Voter Verifiable e-voting scheme (pre-2015)
dSMS messages are not confidential/can be spoofed
eThe Kinect experiment fully meets these requirements: the Leap Motion is less accurate
GB of hard drive): the code was created as a JavaCard 3.0 Connected Edition project running on a simulated platform provided by NetBeans IDE. However, somewhat dis-appointingly, the SCWS has not generally been implemented in real SIMs. Despite the best efforts of the SIMAlliance and OMA in promoting SCWS functionality, the fact that the SCWS is designed to be installed on the SIM raises barriers to adoption, as the MNO owns the platform. This raises ecosystem issues, similar to those that were encountered when NFC technology was first proposed for m-payment applications.
The card-emulation mode available on NFC phones could be used for contactless payments using financial credentials stored on an SE, but there was much debate about the best place to locate this SE. The options are a) on an embedded SE on the phone (i.e. owned by the handset manufacturer), b) on the SIM (i.e. a SIM-SE owned by the MNO) or c) on a removable SE (owned by the user) [320]. The resulting competing management issues caused a barrier to adoption of NFC for use with mobile payments.
Google introduced an HCE solution (in software rather than hardware) for Android Pay [321]: HCE allows developers a quicker route to market for their schemes, albeit without the tamper resistant security of a hardware chip. However, Apple decided to use the embedded SE route to store financial credentials and tokens for their Apple Pay m-payment scheme [113], and NFC m-payment schemes are now more widespread.
By liaising with handset manufacturers, financial institutions can more easily “buy-in”
to the scheme and do not need their own management procedures for direct access to the SE chip. This is a hurdle the SCWS has yet to overcome.
Another implementation issue that affects the SCWS is that it needs support from handset manufacturers to provide modifications to the mobile operating system to in-corporate the required BIP gateway. An open source repository, the SEEK for Android project [322], previously included SCWS features, but they are no longer available at
8.4. Chapter Summary 8. Analysis
time of writing. The SCWS might also benefit from the proposal for a high powered USB contact on the chip, but the lack of available real examples hinders testing. The other communication option, via HTTPs and a TCP/IP stack, will not be possible until SIM cards able to support JavaCard 3.0 Connected Edition become available.
This situation could change in future, as was seen with the NFC m-payment ecosys-tem: a “killer app” or a supportive manufacturer could alter the landscape. Alterna-tively, the functionality and desirable security properties of the SCWS may become available in other security devices/chips, in which case the solutions presented in this thesis will contribute secure applications for this new ecosystem.
8.4 Chapter Summary
This chapter provided a more in-depth analysis of the security features of the SCWS and its applications. In particular, the SCWS defences against relevant OWASP Top Ten 2013 vulnerabilities, and the residual risk of using the SCWS environment were identified. The security analyses of the use cases that had been presented in earlier chapters were then extended. A discussion followed which noted implementation issues for SCWS solutions.