SaFi Bank Space : Project Portunus (IAM PKI PoC)

Created by Norbert Bérci (Unlicensed), last modified on Nov 18, 2022

The goal of Project Portunus is to understand the dependencies and consequences of using Public Key Infrastructure (PKI) for Identity and Access Management (IAM) and includes implementing and evaluating a PoC. It is tracked in SM-1833 - Identity and Access Management (IAM) based on Public Key Infrastructure (PKI) a.k.a. Project Portunus Done

We will implement a PoC that demonstrates the feasibility of the solution described at IAM for Native Apps.

Phase 1

The goal is to demonstrate a working PKI solution.

The PoC should be composed of

  1. An Authentication Service (AS)

  2. A Frontend Application (FA)

  3. A Perimeter Guard (PG)

  4. A Protected Service (PS)

The high level data flow and architecture:

Prerequisites

  • Vacuumlabs git repo for the PoC

  • GCP sandbox with public VM to use for the AS and PS

    • SSH access on port 22

    • port 8443

Authentication Service (AS)

The Authentication Service should be capable of participating in the WebAuthn registration (AS1) and login (AS2) flows as a Relying Party. The registration flow should be compatible with the onboarding flow (as much as feasible for a PoC) (AS3). The login flow should not return any token (AS4). The AS should provide an endpoint where a registered public key can be fetched based on user ID (which is set during the registration flow) in JWK format (AS5). The key store can be an in memory store to ease development, no need to add a conventional database (AS6). If resident credentials is supported by the authenticator, it should be used, otherwise the phone number should be used as the user ID (AS7).

Hints: this service could be derived from a demo WebAuthn server such as https://github.com/Yubico/java-webauthn-server/tree/main/webauthn-server-demo (documentation: https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Server_Overview.html).

For the final solution, we need to use a well established library, for example: https://github.com/webauthn4j/webauthn4j (this is used by https://www.keycloak.org/ and also Kotlin friendly).

Frontend Application (FA)

Research should be conducted about the phone capabilities for PKI use: generic PKI support (R1), secure store support with details about key usage possibilities, e.g. app-only keys, isolation of keys, etc (R2), biometrics support (R3), attestation support (R4). A good starting point about the Philippines phone market is here: https://docs.google.com/spreadsheets/d/1uoBODU0QnO21pezgza7wnxIBx2jizc9A.

The Frontend Application should be capable of participating in the WebAuthn registration (FA1) and login (FA2) flows as a User Agent: it should be capable of generating a public-private key pair (FA3), using the secure store to store the private key (FA4) and using biometrics to provide access to the private key (if biometrics is not available, it should fallback to whatever auth mechanism is required by the secure store, most probably a numeric passcode) (FA5). If resident credentials is supported by the authenticator, it should be used, otherwise the (locally saved) phone number should be used as the user ID (FA6). It is ok if only a very limited phone OS and phone model is supported but at least an iOS and an Android version should be available (FA7).

The Frontend Application should also be capable of using the private key to sign a request (adding the key ID into the request) and sending the signed request to the Perimeter Guard (FA8). The data format should be JWS (FA9).

Background Info

Passkeys

WebAuthn

Developer Hints

iOS

Android

Cross-platform

  • If native platform support is not available, we may utilize a Flutter library like the one from LoginID or any other 3rd party. Seems like a dead end, this library is only compatible with LoginID server API

Perimeter Guard (PG)

The Perimeter Guard should be capable of filtering out requests that are either not in JWS format (PG1) or not signed by a user who’s public key is available via the Authentication Service’s key fetch endpoint (PG2). If this check is successful, it should forward the request to the Protected Service (PG3). If possible, the public key should be cached for quicker check next time (PG4).

Hints: Cloudflare Workers support Web Crypto which could be used to implement the pubkey check functionality. We may also need something above Web Crypto, like PKI.js. These are the technologies used by Cloudflare’s own Origin CA solution (note that we do not want to use Origin CA itself, just as an example implementation by Cloudflare).

Protected Service (PS)

The Protected Service should be able to receive a JWS formatted request from the Perimeter Guard (PS1) and use the Authentication Service to fetch the user’s public key (based on the key ID in the request) (PS2) and use it to check the request data’s authenticity (PS3).

Phase 2

The goal of this phase is to add step-up / re-auth support to the PoC.

Apart from all the components and functionalities of Phase 1, these are the additional requirements:

Step-up Service (SU)

Implement a service called Step-up Service that allows a Frontend Application to execute steps (an authentication journey) needed to receive a step-up / re-auth ID that can be used (via passing to the BE) for subsequent requests where increased security is needed. SU will most probably use Advance AI’s face comparison solution but should be generic enough to support another solution. The journey can be hard-coded, no scripting or any other UI for defining the journey is required.

The SU should provide an endpoint through which the status of the step-up / re-auth ID can be queried. This should support two different IDs:

  • step-up ID: this is a long term ID, can be used for several requests,

  • re-auth ID: this is a single-use ID that should only be used once (by the PS).

Frontend Application (FA)

Should be able to execute a step-up / re-auth journey via communicating with the SU based on the decision by the PS.

Protected Service (PS)

The PS should be able to decide whether it needs step-up / re-auth and communicate it to the FA. It should provide access to increased security services by accepting a step-up / re-auth ID.

Phase 3

⤵️⤵️⤵️⤵️ ⚠️🚧 WORK IN PROGRESS 🚧⚠️ ⤵️⤵️⤵️⤵️

  • by cert: verify via cert passed with request (with AS pubkey)

  • performance comparison with the no cert variant

  • available scaling options

  • key rotation?

⤴️⤴️⤴️⤴️ ⚠️🚧 WORK IN PROGRESS 🚧⚠️ ⤴️⤴️⤴️⤴️