Secure Keystore or enclave in SFOS?

Hi,

Does SFOS have any support for secure keystore functionality? What I’m looking for would be similar to iOS or KNOX etc:

  • safe private key store (generate/write only)
  • digital signing using secure private key

I just came back to the platform with Xperia 10 II, and I noticed that banking app support is as poor as ever. That is one of my expertise areas, and I thought I should investigate if a secure PSD2-compliant banking app could be developed. That would solve the issue at least in the EU.

Br,
//Henri

1 Like

Well, there is Sailfish Secrets.

https://sailfishos.org/wiki/Secrets_and_Crypto

I have no idea how secure the storage for it is though, but if you can evaluate that, it would be great.

To me the bigger hurdle to do anything PSD2-compliant is that it is designed for corporations, and all the FUD around liability that it brings.
I tried to get access to my own bank data through the mandated open API, but unless i’m a corporation, with proper accreditation at that, and a business plan that the bank has to approve, i am not allowed to. And they are fully within their right to require this according to PSD2. …and they want to be able to sue me into the ground at the drop of a hat if anything happens.

If you have a solution to that part, that would be quite cool. I just don’t see what entity could reasonably do this (and still care).

Prompted by this thread i actually started writing on a Citizens Initiative to ask the EU to mandate open options for accessing essential online services (banking/payments, government services). For example when adapting PSD2 to local regulation, the member states would also have to require the issuing banks to provide or otherwise enable platform independent means of identification for online purchases.

I’ll try to put it up somewhere when it has started taking shape, to gather feedback. By now i have seen this crap in too many disguises, so my collection of arguments has become pretty substantial. Anyone reading this: feel free to reach out to me for discussing or helping out, or just giving me a well-needed kick in the rear when i still haven’t published anything in a couple of weeks.

3 Likes

Thanks for the links! It indeed says in there that it may use secure enclave or hardware. So, I guess the next big question is whether something has been implemented in Sailfish X series. Thats a question to you Jolla!

You are 100% correct that PSD2 is not for individual or free data access. If you want to do it, it must be commercial software. We here do consulting in that area so we know this very well…

What I was thinking, that we could make an affordable app that would let you connect to multiple PSD2 enabled banks. Licensing and the whole concept is still completely in a thought stage, but I think for example 10€/year for it could be reasonable. It would be just for basic banking, paying bills and face-to-face transfers.

Happy to hear thoughts and feedback from everyone!

//Henri

2 Likes

Come to think of it; there is also this app GitHub - Wunderfitz/harbour-zaster: A banking client for Sailfish OS
It seems to pre-date PSD2, and maybe have had some issues because if it(?) and i’m generally not sure about the status.
Perhaps @Ygriega can weigh in on things.
For me the biggest problem with it is that i’m not in Germany :slight_smile:

Yes, 10€/year would be very reasonable in my opinion. And while i’d like to see a proper open solution, i certainly wouldn’t mind paying 10€ for running it and dealing with liability. I’d even pay for a closed or semi-closed service as long as it is not actively working to entrench that situation.

Maybe this is due to having used Sailfish all my smartphone life, but i’m also honestly not sure i need or want mobile banking (beyond mobile payments). To me banking is best done sat down with a keyboard and proper monitor. But i would be a paying subscriber to such a service none the less, purely out of principle.

PSD2 SCA is my main concern.

I would definitely not write a new PSD2 stack from scratch for open source’s stake. There are solutions that are relatively affordable and integrated to 100’s of banks already. I’d keep it as open as feasible though.

For SCA SFOS is OK for the time being, but its possible that secure keystore requirements will come up in the near future.

2 Likes

I understood your question to be directed at what this question elaborates a bit further:
[idea] SFOS Support for Secure Elements (SE) (or Trusted Execution Environment (TEE))

Yes, that is 100%
But as I have understood, no developmets.
(Jolla prove me wrong!)

1 Like

I went reading this sailfish-secrets project a bit.

IMHO, its too complex to get traction. Talk about certs etc. None of that is really needed, if you want to do safe stuff with SFOS!

Now:

  1. You cannot use such a mechanism securely for shared secrets (like passwords). It will not work. Passwords suck, and its not fixable.
  2. You only need few simple mechanishms:
  • creation of ECC keypairs
  • secure store of the private key
  • ECDSA by pushing data and getting SHA’d signature (and verification vice versa)
  • ECDH is nice, but not mandatory.

In my opinion, there should be just a simple api for basic operations, and thats it. Maybe then it would be conceivable to use the HW, if you only do keygen and ECDSA.

Anycase I don’t know much about how the Xperia 10 HW is integrated. I know little bit about Samsuing Knox, they have nice API for this crap. SFOS absolutely needs this, if there is any interest for banking and pro enterprise auth things.

While it is complex, I do not agree with the “too”, because …

… I wholeheartedly disagree with this assessment.
These things are essential for Jolla’s target customers, who supposedly want a proper and secure MDM etc.

This approach does not work (properly and securely), as many have discovered in the past.
Prime example is GnuPG1 vs. the GnuPG2-framework (comprised of libgcrypt, gpg, gpg-error, dirmngr, gpgme and more).

The “simple API” approach always resulted in software being written, which is insecure, because it uses that “simple API” incorrectly, does not adhere to “crypto best practices” etc. etc.

TL;DR: Don’t!

No, I cannot see that SFOS needs Samsung’s “Knox”.
I also cannot see how that would be technically feasible.

And any SFOS-specific API will not be used by banks anytime soon, because there are way too few users.

1 Like

I think you are reading now too much on this “simple API” concept.

Of course, if you want to give full secure control, make a secure enclave thingie. But I don’t think that is possible in current hw and OS (Please tell me I’m wrong!)

One ugly fact, is that in Linux (meaning ANY Linux) there is no sufficient client-level crypto keychain system. If you want import P12 key to Ubuntu for TLS Client Certification, you have to do that it in the browser. Double click goes to some strange GPG thing, that does not even work :frowning:

This is extremely unimpressive. Windows 10 and OSX can handle that one, their keychains can actually import and USE keys/certs. I have no idea how to do this in SFOS.

I will take most of this back, if someone tells me how to:

  • Import pkcs12 file for browser usage
  • Use that keypair for client-cert tls
    (all that with a browser that actually works)