Abstract

By implementing an strong customer authentication (SCA), lemon.markets increase the protection of sensitive financial information by preventing unauthorized access and mitigating fraudulent activities. Continue reading to learn how this is done.

Context

Strong Customer Authentication or SCA, involves verifying the customer's identity using at least two independent authentication factors from three categories:

Knowledge: Something only the customer knows, like a password.
Possession: Something only the customer possesses, like a mobile device.
Inherence: Something unique to the customer, like biometric data.

By implementing SCA, lemon.markets can significantly reduce the risk of sensitive actions being performed without customer consent. Due to the nature of our business those cases may go from placing an investment order to performing a withdrawal transfer.

Usage Principles

lemon.markets requires all brokerage use cases to be secured via strong customer authentication. This approach ensures compliance with respective regulatory requirements as well as increased security, ultimately benefitting the customers.

The responsibility of implementing SCA is shared between lemon.markets and their partners.

All applicant customers must perform SCA enrollment by the end of the account opening process to finish their account provisioning.

Use Cases enforced by lemon.markets

Customers will have to respond to SCA challenges in order to confirm the action. The API will require a fresh SCA challenge for the actions like these:

Placing an Investment Order, e.g. the customer places a buy or sell order to the market or changes of a saving plan.
Payout action (withdrawal), e.g. the customer requires a money withdrawal to their reference bank account.

Use Cases outsourced to Partners

In order to ensure complete app security, partners need to protect their whole application experience starting from log-in/session opening. This will maintain all remaining customers interactions under the SCA umbrella.

Access to customer information, e.g.
- Read access to customer personal information
- Read access to customer brokerage information, including current and past investment information
- Access to customer documents, including tax-related ones

As mentioned above, the partner contract agreement will outline this requirement.

Technical Standard

lemon.markets has decided to implement SCA following the patterns and principles outlines in the WebAuthn standard. WebAuthn is a well-known solution, strong enough to be compliant with FIDO2, while user-friendly enough to allow integration with authenticators built-in to mobile devices having the latest facial or fingerprint recognition features, e.g. FaceID and TouchID.

You can find more details on WebAuthn in the WebAuthn Guide.

Test Vectors

The following section will guide you through the registration and signing processes. We offer a way to provide a signature when registering a key, so implementors can be assured that any public key registered with lemon.markets can actually work with their implementation.

1. Registration

Given the following 2048-bit RSA private key is generated on a device (PEM, PKCS8 format):

The associated public key will be the following:

When decided to use the signature algorithm PKCS1 v1.5 with SHA256 the COSE representation for the key is:

{
  1: 3, // Key Type: RSA
  3: -257, // Signing Algorithm: RS256 (RSASSA-PKCS1-v1_5 using SHA-256)
  -1: <RSA public key numbers N, max. 256 bytes big endian format>,
  -2: <RSA public key numbers E, max. 256 bytes big endian format>
}

For details on the encoding, see the section “References” at the bottom of this document.

The final base64-url encoded representation is this:

pAEDAzkBACFZAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABIFkBAM5PQMI1OJEzX5gQe5c5UvIP
4vXebP1xUY7IDYDpTMuOlShmaNooayTp20AlV2f4xH4Y2SGtaEZehhmtiVQKpwnY
c6re7wWxhvuPKiHG3t80hYg-Mb0jr1-W1D32mxqEgPv_fkUumJiUmvjE29FhYg2R
yeRg63xTm8o_1y3GNMoz4xC95DXXaP1TmKifRmvMy1sE5yo3dSt9yd0WSvjJvyCz
ZZwwYUkIJlhEaIuHp2amwIHlFmyv9KxwA0ILgyVVPVIoeoDOW-qPxgxlZG5q1iUl
tfTkdjMIYDIvT8kh6uaScyEazU8QPhlkDrccufNWdGjFXQtQxEng254UvmGtYxc=

(Line breaks added for legibility.)

2. Signing

Given the key pair from above and the following challenge:

raw: b"test"
base64url: dGVzdA==

The resulting valid base64 url signature would be:

YgRpMIpOo3IFSGOrWPB0sxkVZmKduhoAmBH3R7YBFjm_V96AOCA8P-q9BOC_OnP8
jNocT2u8J_i8ZIE10LMTEhRtzBi2ve9bgfD0CZCn7R6UWznz67KQs-DqRn0_4IcT
S3MnYNQ_AEzUW5eDAp2P4hb3cVZ2go1PIHSC990rbmkUGjPp-4NE7aHJ-P4F7gEw
HVYimYoH4jAV3vCaiGiYdr-46wfdxuok3i4IasCo3CfVFuJQzl8pr6E_0NfKFO2D
dDk88_jt7vKTqFCAsNN1x1S0H8uMao8ccX1QRktXeJ0DfjQwne7NSgQCGa3tKX54
NrtCizzmwtGkX8BLNKQDtA==

(Line breaks added for legibility.)

3. Bringing it All Together

Now we can create the payload to register the key and ask the backend to verify our signature. As you can see, you are free to omit the base64-url padding character = at the end of the payloads:

{
  "client_credential_id": "<local identifier>",
  // public key truncated for clarity
  "public_key": "pAEDA[…]GtYxc",
  "verifier": {
    "nonce": "dGVzdA",
    // signature truncated for clarity
    "signature": "YgRpM[…]KQDtA"
  }
}

You can now POST this payload (with all the other authorization and data-privacy headers) to /v1/accounts/{account_id}/authenticators.

Outlook: Elliptic Curve Cryptography (ECC) Considerations

Attached, you'll find the COSE representation of an EC public key:

{
  1: 2, // key type EC,
  3: -7, // key algorithm used for signing: ECDSA SHA256
  -1: 1, // curve used for the key pair 1 = secp256r1
  -2: <EC public key numbers X, 32 bytes big endian format>,
  -3: <EC public key numbers Y, 32 bytes big endian format>
}