Page 14 - FIGI: Security analysis of the KaiOS feature phone platform for DFS applications Security, Infrastructure and Trust Working Group
P. 14
5 ANALYSIS
Having described KaiOS’ security model in Chapter authenticated communication and secure coding
3 and its limitations in Chapter 4, this Chapter analy- practices to harden the app�
ses the extent to which KaiOS can fulfil the security
requirements set forth in Chapter 2. Encryption, authenticated communication and
secure coding practices can be implemented in
R 1� Consider the use of strong authentica- JavaScript, fulfilling this requirement.
tion mechanisms to demonstrate ownership of the
device� R 4� Apps should be subjected to external secu-
rity review and penetration testing, and any recom-
Because it lacks biometric sensors, the only way mendations acted upon�
to lock a KaiOS phone is to set a PIN code, which is
typically limited to four digits. Without biometry, The fact that the apps are delivered as a set of
long PIN codes or passwords, it is not possible to HTML, JavaScript and CSS source files gives easy
have a strong authentication of the phone’s user. access for security reviews.
As long as the PIN is not stored in a secure ele-
ment on the phone, it is also highly probable that R 5� Apps should securely manage username
physical access to the phone would suffice to and password information so that adversaries
bypass the lock screen PIN. cannot easily forge credentials, and should use
Since the phone includes a SIM card, it contains a strong authentication mechanisms to protect
strong authentication mechanism to authenticate against unauthorized access�
against the mobile network. The PIN code of the
SIM card authenticates the user and cannot be KaiOS does not provide a hardware assisted
bypassed. Therefore, KaiOS phones can indeed secure storage of secrets. Therefore, the secrets
provide a strong authentication mechanism, if the of all other applications are only one browser bug
DFS is ran by the Mobile Network Operator (MNO). away.
It is unfortunate that KaiOS has disabled the API
that allowed an application to get an attestation R 6� Regular security updates are critical to
of the phone number from the SIM card (mobil- ensure that mobile operating systems running
eID). This would have allowed other parties than on user devices operate using the latest security
the MNO to strongly authenticate a phone. Thus, patches�
now an app can no longer benefit from the strong
authentication of the SIM card. The drive to make feature phones as affordable
as possible is in contradiction with the effort to
R 2� Make use of hardware and software mech- provide regular updates of the operating system.
anisms within mobile devices, such as secure On the other hand, KaiOS makes it quite simple to
elements and TEEs, which can ensure device integ- provide updates for hosted applications.
rity, and promote the use of devices equipped with
security features for use in DFS� R 7� Ensure that security libraries offered by the
operating system are correctly designed and imple-
This is currently not the case, but as mentioned mented and that the cipher suites they support are
in section 4 , secure elements could be added to sufficiently strong�
KaiOS phones in the future.
KaiOS is based on widely used software compo-
R 3� Whether an application is designed for nents (Linux, Gecko). There should not be a signifi-
deployment on the handset or secure element, cant difference between the security of its libraries
it should be designed and implemented in accor- and the ones of smart phone operating systems.
dance with best practices, including encrypted and
12 Security analysis of the KaiOS feature phone platform for DFS applications