We have moved to a new Sailfish OS Forum. Please start new discussions there.
19

Is Sailfish OS PSD2 compliant?

Tracked by Jolla

asked 2019-05-15 16:03:51 +0200

Federico gravatar image

updated 2019-05-15 20:57:51 +0200

The EU has approved a new security standard called PSD2 for online banking authentication, effective due September. The most visible consequence is that 2FA hardware tokens like this one must be phased out; only second factors that can display additional information about the payment (receiver and amount) can be used. This means that most banks that are still using hardware tokens will switch to SMS messages or smartphone apps as second factor.

Also, the new standard mandates that the second factor must be independent and segregated from the application that does the online banking via "separated secure execution environments". It seems to be accepted that one can do e-banking on Android and Ios (from an app or from a mobile browser, via the bank's website) using SMS messages or bank apps as a second factor, because even if both "factors" reside on the same device, on these systems the apps are sandboxed and segregated one from another.

Sailfish OS does not sandbox its apps nor puts them in "separated secure execution environments", as far as I understand. Hence, it seems to me that e-banking on a native browser on Sailfish OS is not going to be PSD2 compliant, when paired with SMS messages or even with an Android-based 2FA app running on Aliendalvik.

Is my reading correct? If so, that seems problematic for the future of the OS. Banks could, in theory, block Sailfish browsers, or they could legally leave Sailfish users on their own in case their account gets hacked. And the reputation of being "not a safe enough OS for online banking" is truly a terrible one to have.

edit retag flag offensive close delete

Comments

I'd certainly consider the SIM card that authenticates the user to the network over which he or she receives the verification SMS to be separated and secure. The actual delivery of that information may not be entirely so, but does/should that actually matter?

attah ( 2019-05-16 00:13:35 +0200 )edit

I'm just interpreting the directive and IANAL, but in my view (1) the whole point is to ensure a secure "delivery of that information" (2) the spirit of the rule is: how many distinct attacks do you have to successfully perform to get my money? In case of Android/Ios it's 2; in case of a rooted Android or Sailfish it's 1. Point 3b in Article 9 (cited in my last link) seems to refer to rooted Androids, but it's not entirely clear to me what it entails.

Federico ( 2019-05-16 00:55:37 +0200 )edit
1

@Federico: Thank you for your valuable reminder and excellent text. Well done! I have filed a task for our R&D to investigate what should be done.

jovirkku ( 2019-05-16 09:05:39 +0200 )edit

@jovirkku Thank you and Jolla for giving attention to this issue!

Federico ( 2019-05-16 10:07:03 +0200 )edit

1 Answer

Sort by » oldest newest most voted
11

answered 2019-05-16 17:36:01 +0200

DrYak gravatar image

Sailfish OS does not sandbox its apps nor puts them in "separated secure execution environments", as far as I understand.

Not exactly.

First keep in mind that Sailfish is a too small ecosystem and no bank will deem necessary to develop a special app targetting Sailfish. You're most likely going to run an Android application on Sailfish's Alien-dalvik Android Application compatibility layer.

Now...

Android isolation

On modern Sailfish X (with Baseport 8) as used on the Xperia XA2, the Alien-dalvik Android Application compatibility layer works by running an AOSP (opensource Android) 8.1 Oreo inside an LXC (a type of Linux Container) which will result in the android being kept separate from the rest of Sailfish X.

(And on older Sailfish as used on Xperia X, Jolla 1, etc. : Those devices use AOSP 4.4 Kitkat and by design these older versions of Android run inside some kind-of Java VM. They are already in a VM, they already run separated from the rest of the OS, by virtue of running bytecode in the Dalvik JVM).

So the whole Android is already sandboxed to begin with, on Sailfish.

Android APPs isolation

Because Sailfish runs the "real-deal" AOSP (either in LXC or inside a JVM), you will automatically get all the application isolation that is automatically provided by Android.

e.g.: If you explore the content of /home/.android/ you'll notice that, just like on real Android smartphone, each application is installed under a different UID and GID.

So if one app get hacked, it will not be able to access the data of another app without need first to do privilege escalation (and hack the whole system becoming root).

So, from the point of view of banking APP, running them on Sailfish OS looks just like running on a real Android smartphone

The problem won't be due to the application environment but for the services

Google Proprietary Service

Like lots of other android applications, some of the banking applications are addicted to the APIs provided by the "Google Play Service" (proprietary blobs of Google, not part of the opensource AOSP).

You have two solutions to get this working in Alien Dalvik:

  • install the actual Google Play Service from Google

    (Note: I haven't tried it personnally)

  • install MicroG (an opensource program which re-implements the same APIs)

    it provides most of the APIs, including the SafetyNet features (see DroidGuard Helper).

In my experience MicroG is plenty enough to keep my Bank's 2FA happy.

Note: some applications, like mine, might complain also when they don't see the "Google Play Store" (com.android.vending) present. If you don't have it, e.g.: because you use FDroid, Yalp Store and/or the Aptoid provided in Jolla's Store, you'll need to install the dummy package FakeStore from MicroG, to keep them happy.

Note: some other application, according to discussion on this forum, require SafetyNet. Install DroidGuard Helper from MicroG and enable the feature in MicroG's Settings.

Root

There's no su inside Alien-Dalvik to begin with. (On Sailfish OS usually we do most of the admin stuff from within the full GNU/Linux).

Your banking app shouldn't complain about that. If it is complaining about "root" or "SU", usually it's because one of the other tests mentionned above fails. You might need to install FakeStore, or to enable SafetyNet.

Browser

You'll have an entirely different problem here:

The native Sailfish OS Web browser is still based on a very ancient version of Gecko. (Though according to the latest official blog from Jolla Devs, they are working on this so progressively the situation should get better over the next couple of upgrades).

So you're not going to be able to browse to your bank's website. That's not because they're boycotting Sailfish for not being compliant (in fact, it will be better sand boxed than other, simply because the main OS and Android are sand boxed from each other through LXC), but simply because the browser is too old and probably won't work.

You can temporarily get around that by install Mozilla Firefox for Android (e.g.: from the Aptoid Store) or Bromite from the FDroid store (a mod of Chromium with AdBlocking as an extra).

Even if you're not leveraging the OS-level sand boxing (LXC), you're still benefiting from the in-Android normal app sand boxing, so your Bank should be happy.

edit flag offensive delete publish link more

Comments

1

This seems a great answer, but I am not fully convinced by it. Yes, Android apps are segregated one from the other and installing one malicious Android app will not compromise the rest of the system. But, from what I understand, native Sailfish OS apps are not isolated, and installing one malicious Sailfish app will allow an attacker to compromise the whole system, including gaining access to all the data that resides in the Android sandboxes. Is this correct?

Federico ( 2019-05-18 13:08:06 +0200 )edit

Where did you read that SailfishOS uses Android inside LXC? It looks like it is not the case according to this question: https://together.jolla.com/question/107023/running-android-in-lxc-container/ Note that not all Android apps run inside a JVM, some are using native code. Also I think a JVM does not provide more security against a spyware, for example a keylogger or screenshot app running in a background process.

baptx ( 2019-10-12 15:53:13 +0200 )edit
Login/Signup to Answer

Question tools

Follow
12 followers

Stats

Asked: 2019-05-15 16:03:51 +0200

Seen: 1,470 times

Last updated: May 16 '19