Analysis and Conclusion
8.2 Security Analysis - Use Cases
• Attack Scalability: Remote attacks on the SCWS are difficult, due to its trusted access protocols, and remote DDoS attacks are hard to mount. However, a DoS attack against a single SCWS is feasible, as attacks on the SCWS from the phone browser are theoretically possible, but these are not scalable because the attacker would also need physical possession of the handset.
8.1.2 OWASP Top Ten Risks
The Open Web Application Security Project (OWASP) [135] issues a document which includes the Top Ten vulnerabilities that affect the security of web applications1 .
As the SCWS is a web server, these vulnerabilities could affect the security of SCWS solutions [316]. However, some of the OWASP Top Ten do not apply to SCWS applications.
Table 8.1 shows which of the OWASP Top Ten 2013 apply to the SCWS environ-ment. Vulnerabilities A5 (Security Misconfiguration), A6 (Sensitive Data Exposure) and A9 (Using Known Vulnerable Components) are shown as not relevant to SCWS so-lutions. This is due to the tamper resistant characteristics of the SIM card, along with the small footprint, minimal functionality and tightly controlled management of the SCWS which should provide assurance that credentials are kept securely, and system components remain up-to-date and configured properly.
The injection and cross site scripting exploits - A1 (Injection), A3 (Cross-Site Script-ing (XSS)) and A8 (Cross-Site Request Forgery (CSRF)) - can be limited by strict filtering of input fields in the phone browser. The reduced complexity of the stripped down SCWS also affords some protection against these vulnerabilities. It should be noted, however, that many of the OWASP Top Ten relate more to application design and implementation rather than web server functionality (i.e. A1, A3, A8 and A10).
Table 8.2 summarises the SCWS defences against applicable OWASP Top Ten 2013 vulnerabilities and the residual risk from using the SCWS environment.
8.2 Security Analysis - Use Cases
The security of the use cases presented in earlier chapters of this thesis is now revisited.
For each use case, security requirements were identified and an informal security anal-ysis was done: when appropriate, formal analanal-ysis using Scyther was also performed,
1When the research in this thesis was done, the most recent OWASP Top Ten was from 2013: the OWASP Top Ten - 2017 [315] was released in December 2017. In the 2017 version, A4 (Insecure Direct Object References) and A7 (Missing Function Level Access Control) were merged into a new category A5 (Broken Access Control), whilst A8 (CSRF) and A10 (Unvalidated Redirects and Forwards) were retired.
8.2. Security Analysis - Use Cases 8. Analysis
Table 8.1: OWASP Top Ten 2013 and Relevance to the SCWS
Reference Description SCWS
A1 Injection Untrusted data is sent as part of a command or query e.g. SQL (Structured Query Language) or LDAP (Lightweight Directory Access Protocol) that can trick an interpreter into executing unintended commands or access unauthorised data.
Yes
A2 Broken Au-thentication/ Ses-sion Management
Attackers can compromise passwords, keys, or session tokens, or exploit other implementation flaws to as-sume other users’ identities.
Yes
A3 Cross-Site Scripting (XSS)
If an application takes untrusted data and sends it to a web browser without proper validation, attackers can execute scripts in the browser e.g. to hijack sessions, or to redirect unsuspecting users to malicious sites.
Yes
A4 Insecure Di-rect Object Refer-ences
A direct object reference concerns an internal imple-mentation object, e.g. file, or directory: poor access control can lead to manipulation of these references by attackers and unauthorised access to data.
Yes
A5 Security Mis-configuration
Applications, frameworks, and servers should have a secure configuration defined and deployed: these must be implemented and maintained (defaults are often insecure), as well as keeping software up to date.
No
A6 Sensitive Data Exposure
Weakly protected data could be tampered with, so sensitive data at rest/ in transit should be encrypted:
care should be taken when exchanging data with the browser.
No
A7 Missing Func-tion Level Access Control
Applications must perform verify function level access control checks on the server, otherwise attackers will be able to forge unauthorised functionality requests.
Yes
A8 Cross-Site Request Forgery (CSRF)
A forged HTTP request is sent from a logged-on vic-tims browser to a vulnerable web application that will then be treated as a legitimate request from the victim
Yes
A9 Using Known Vulnerable Com-ponents
Applications using components such as libraries, frameworks, and other software modules with known vulnerabilities may result in a number of attacks.
No
A10 Unvalidated Redirects and Forwards
Without proper validation, attackers can redirect users to malicious sites, or use forwards to access unau-thorised pages.
Yes
8.2. Security Analysis - Use Cases 8. Analysis
Table 8.2: OWASP Top Ten 2013 - SCWS Defences and Residual Risks
Ref Defences Residual Risks
A1 The SCWS does not support SQL or LDAP so SQL/LDAP injection at-tacks do not apply here.
Non - SQL/LDAP injection attacks targeting input fields may occur.
Filtering of input will be needed.
A2 All credentials are stored inside the tamper resistant SIM card, and secure HTTPs connections protect credentials whilst in transit.
Even if data from one phone leaks, this affects one device only, and an attacker would need to be in posses-sion of the phone.
A3 Strict filtering of input fields will be needed.
Limited complexity provides a cer-tain level of assurance.
A4 Applications on the SCWS may have different levels of access (e.g.
admin/ user), so proper authorisa-tion and verificaauthorisa-tion of all access re-quests should be done.
There is nothing in the OMA spec-ification that forbids an SCWS ap-plication to have multiple users on one SCWS, but in practice this vul-nerability may not apply.
The phone browser is allowed to ac-cess a webpage in the SIM card, so attacks may arise (e.g. through phone malware).
A8 The SCWS should be able to imple-ment CSRF countermeasure such as forcing a user to re-authenticate.
The SCWS has restricted function-ality which provides added defences.
A10 Redirects should be validated. Manipulation of the server side (the tamper resistance of the SCWS should protect against this) and the phone browser would be needed, which is a difficult attack to perform successfully.
and no attacks were found within bounds. The results are summarised in Table 8.3. It can be seen that the security requirements were, on the whole, well met.
Solutions presented for the use cases fall into two categories: SCWS-based (i.e. EV-1/2, MP-1, Auth-1 and VW-1 ) and non-SCWS-based (i.e. MP-2, Auth-2 and VW-2 ).
These categories are now discussed.
8.2.1 SCWS-based Solutions: EV-1, EV-2, MP-1, Auth-1 and VW-1 Each of these solutions exhibits the following characteristics that enhance security in challenging environments:
• Identification: All the presented SCWS solutions provide two-factor
authenti-8.2. Security Analysis - Use Cases 8. Analysis
cation of users, by using a correct PIN/Password for accessing the SCWS envi-ronment (“something you know”), in conjunction with possession of the SCWS (“something you have”). Local authentication is possible, which is particularly relevant in use case Auth-1. Additionally, use case EV-2 demonstrated that it is feasible to use the SCWS with National PKI schemes, using Estonian I-voting as an example. Estonia has been called the “most advanced digital society in the world” [317], but there are national PKI schemes being proposed for other (possibly less technologically developed) nations such as Kenya [318] and the Philippines [319], that could consider the SCWS approach for remote e-voting using mobile phones.
• Connectivity: To install and update code and data on the SCWS, there must be connectivity: however, much of the other processing can be done offline without loss of security. So, votes can be cast offline in EV-1/2 and retrieved at a later time, authentication can be done wholly offline in Auth-1, and transfer requests can be made and processed at a later time in MP-1. However, face-to-face trans-actions such as withdrawals and deposits need to be communicated to and from the bank in a reasonable time. Offline processing is not relevant to VW-1.
• Attack Resistance: The small attack surface of the SCWS, the tamper resis-tance of the SIM, and the resilience against DDoS attacks provided through dis-tributing applications to a large number of SCWS/SIMs all reduce the likelihood of attacks succeeding. Attack resistance is a welcome security feature, especially when technical expertise may be scarce in the relevant operating environment.
This applies to all the use case solutions in this category.
8.2.2 Non-SCWS-based Solutions: MP-2, Auth-2 and VW-2 The three remaining use cases did not use the SCWS in their solutions.
The Bitcoin m-payment solution MP-2 was designed to bring the security of dis-tributed ledger transactions to areas with the minimum available connectivity i.e. SMS messaging only. It would be possible to use the SCWS to store credentials, and process transactions on the SIM as in use case MP-1, by issuing advanced SCWS/SIMs instead of the OTP token. The SCWS could generate OTPs as required, and send transaction details via secure HTTPs communication and the RAS. However, SCWS transactions need some online access to communicate between the RAS and the SCWS, so this may not be a suitable option in the targeted environment. Also, the need to have a business relationship with the MNO that owns the SIM would reduce the immediate deployability/ interoperability of the m-payment scheme in humanitarian aid scenarios,