CIBA: security issues

[Tom Jones]

I believe that the security level of CIBA is not well understood and would add the following text.

A client initiated backchannel is not difficult to intercept by a hacker, see https://www.forbes.com/sites/laurashin/2016/12/21/hackers-are-hijacking-phone-numbers-and-breaking-into-email-and-bank-accounts-how-to-protect-yourself/. So the only additional security is that the user at one time had control of the account identifier (such as phone number) that was recorded by the client from the user. It does not provide the proof of possession of the client device that is addressed by that account identifier and so does not add an authentication of "something the user has" without additional proof of possession information.

[Gonzalo Fernández]

I don't know if I understand you well, but I don't see the difference between CIBA and the front-channel to provide proof of possession. In both cases the user will receive a text related with the ongoing authentication transaction to accept or reject the transaction and is the user's answer what provide the proof that it is the owner of the device. However this kind of authentication by means of the demonstration that the user is the owner only accepting the transaction without giving any additional informatiion like a secret, pin code, etc... has a weakness in case of the terminal is substracted or the message is intercepted. And I think that it only can be resolve increasing the level of assurance as you said, but I don't see it is a problem related with CIBA spec.

[Tom Jones]

Actually my point was that the client cannot know what device responds unless a proof of possession token is required.

[Nat Sakimura]

The client should include mod-pr in acr_values. The likely outcome in the amr would be a combination of user and swk or hwk.

@xixon2002 , is there a way for a mobile operator to find the connection is actually from the handset that is associated to the ISMI? I remember that there was discussion around GBA back in 2009 or so but I am not sure where it landed.

[Tom Jones]

It seems like you are saying that a telco can ask a device lots of questions to determine if that is the device that is currently registered to a user. I cannot imagine any way that this mitigates the attack listed. None of the telcos that i have ever used have been concerned if i am a real person, only if i can pay the bill. In fact i have never heard of any non-sovereign IdP (OP) that ever would make a definitive statement about the real identity of their users or at least to take any liability for a broken identification. If anyone doubts this, just logon to your telco account and see how easy it is to change the device.

I really do not know why this is being done in FAPI. Is there any evidence that a bank would rely on a telco? Or even share information with one? If CIBA were divorced from the telco i can see lots of ways to use the ARM (or Intel) trust zone to perform this function, but not with a telco.

[Gonzalo Fernández]

Hi Nat,

Telcos companies do know the device associated with a user, in fact they use such information to improve customer care when he calls for something related with the device. As far as I know, when the terminal has been registered in the network, it sends the IMEI and thanks to that the operator is able to know the device and associated it to the MSISDN and IMSI because at this time it also has that information.

[Tom Jones]

To be really clear then. Only the telco can support CIBA, correct?

Note that i voted against the MODRNA specs because, IMO, they do not uphold the user consent requirements in OpenID Connect. For FAPI to endorse the telco involvement in a financial transaction would exacerbate this failing.

Peace ..tom

[Dave Tonge]

@tomcjones there seems to be some confusion here. The CIBA profile provides a standard for backchannel auth. It is not tied to mobile phones even, it is just that the first "use case" was for Mobile Connect.

In FAPI we are proposing that banks use CIBA in the following way:

1. A bank onboards a customer to the bank's mobile app (this is in the competitive space, but this onboarding process should hopefully include the generation of a key-pair, with a private key that never leaves that device).
2. The customer uses this banking app for everyday banking interactions - the bank can obviously implement this in any way they see fit
3. The bank implements CIBA and defines some login_hint that third parties can use to start a CIBA request - this could be a username, an email address, a card number, etc.
4. When the bank receives a CIBA request from a valid client with a valid login_hint, it sends a push notification to the user's device. (NB, not an SMS, but rather an Apple or Android push notification)
5. The user opens their banking app from the push notification and is shown a consent screen where they can authorize the requested access
6. Once the user authorizes the request, the client is issued an access token

(NB the flow will probably include the comparison of binding messages, but we are still working through the detail of that)

The bank should have a strong assurance that it is interacting with its user, as it will have taken the user through an onboarding process to set-up the app.

An attacker couldn't spoof this flow by hijacking the user's phone number as the flow doesn't use SMS messages or any telco based identity factors.

If an attacker hijacked the Apple / Google push notification system, the flow still wouldn't break as the banking app would need to retrieve the consent details to display directly from the the bank's servers.

Hopefully this clarifies the proposed use case of CIBA in a FAPI context.

Dave

[Dave Tonge]

Tom, there seems to be some confusion here. The CIBA profile provides a standard for backchannel auth. It is not tied to mobile phones even, it is just that the first "use case" was for Mobile Connect.

In FAPI we are proposing that banks use CIBA in the following way:

1. A bank onboards a customer to the bank's mobile app (this is in the competitive space, but this onboarding process should hopefully include the generation of a key-pair, with a private key that never leaves that device).
2. The customer uses this banking app for everyday banking interactions - the bank can obviously implement this in any way they see fit
3. The bank implements CIBA and defines some login_hint that third parties can use to start a CIBA request - this could be a username, an email address, a card number, etc.
4. When the bank receives a CIBA request from a valid client with a valid login_hint, it sends a push notification to the user's device. (NB, not an SMS, but rather an Apple or Android push notification)
5. The user opens their banking app from the push notification and is shown a consent screen where they can authorize the requested access
6. Once the user authorizes the request, the client is issued an access token

(NB the flow will probably include the comparison of binding messages, but we are still working through the detail of that)

The bank should have as strong an assurance that it is interacting with its user as any other time that the user is using the banking app.

An attacker couldn't spoof this flow by hijacking the user's phone number as the flow doesn't use SMS messages or any telco based identity factors.

If an attacker hijacked the Apple / Google push notification system, the flow still wouldn't break as the banking app would need to retrieve the consent details to display directly from the the bank's servers.

Hopefully, this clarifies the proposed use case of CIBA in a FAPI context.

Dave

[Tom Jones]

let me be sure i understand as it seems that some steps were missing. - The full use case.

The customer initiates a connection with a client. The client initiates an OpenID Connect connection with the OP, in the case with the bank. (i don't think any other OP would do based on rest of flow.) Before or as a result the customer is authenticated to the bank. The customer initiates some value transaction to the client which somehow can ID the device among the many that the consumer might use. The client sends a CIBA request to the OP (the consumer's bank). That is the only way for all to have the consumer's sub and the device ID. The bank initiates CIBA to the consumers device as specified via the client. The consumer allows the OP app to run (i assume that this is in no way considered to be a client.) The consumer consents to the payment to the OP. The bank now confirms payment to the client.

is that right? ..tom

Peace ..tom

[Bjorn Hjelm]

Tom, I’m not sure I understand the reasoning behind the statement that “only the telco can support CIBA”?

BR, Bjorn

From: Openid-specs-fapi [mailto:[e-mail]] On Behalf Of Tom Jones via Openid-specs-fapi Sent: Tuesday, November 28, 2017 8:13 AM To: Gonzalo Fernández; Financial API Working Group List Cc: Tom Jones Subject: [E] Re: [Openid-specs-fapi] [Bitbucket] Issue #127: CIBA: security issues (openid/fapi)

To be really clear then. Only the telco can support CIBA, correct?

Note that i voted against the MODRNA specs because, IMO, they do not uphold the user consent requirements in OpenID Connect. For FAPI to endorse the telco involvement in a financial transaction would exacerbate this failing.

..tom

Peace ..tom

[Tom Jones]

Sorry that i do not currently have the time to complete a full threat analysis of CIBA, but here is my current understanding.

There are two hardware protected means for any service to determine the identity of a device: 1. The sim card which is AFAIK only accessible to the telco 2. The ARM trust zone (aka TEE) that is not available in any telco provided implementation (YOLO may fix that, or may always require a rooted device)

The software protected modes AFAIK are the notification methods supported by ios and android. The security of those is not at a hardware level and needs a complete threat analysis. If any one knows of any analysis it would be good to reference it. My base assumption is that an exploit will be found.

[Dave Tonge]

I believe this issue can be closed. We had a discussion on the call about the fact that it is expected that CIBA implementations will not use SMS, but will rather use push notifications.

[Tom Jones]

i disagree. The point was that the security section should outline the limitations. Discussing them on the list does not add them to the spec. Let's add the security considerations, including expectations, to the spec.

[Tom Jones]

To be more explicit about the vulnerability that must be prevented. The user's phone company account password is released. This can happen in the normal course of business, say a divorce where the spouse needs to transfer their phone number to another account. The attacker registers a new device for the user's phone number. This attack has already happened in Europe. The attacker loads the bank's client on their phone and then asks the bank to reset their password based on the purloined phone number. Now the attacker has full access to the user's bank account.

Based on an account by Ross Anderson the UK banks have already forced their users to take full responsibility for losses at the atm. It is most likely that they will force users to take full responsibility for losses if the phone is used to reset the account. I suspect that there is some sort of requirement that the banks use internationally recognized standards to enforce those terms. I don't want to see the FAPI standards used to add liability to bank account users. Nor to i want to read a report by Ross Anderson about the weakness of FAPI standards.

[Dave Tonge]

Hi Tom, I understand your point.

I' can add a security consideration something like this:

Authentication Device Compromise

This profile and the underlying spec do not specify how the Authorization Server should initiate and perform user authentication and authorisation of consent on the authentication device. However Implementers

• should not use insecure transport protocols when notifying users, for example SMS is subject to vulnerabilities in the SS7 protocol.
• should not rely on the users possession of a sim card as a sufficient authentication factor as an attacker may be able to fraudulently obtain this via social engineering.

[Dave Tonge]

Just to add that CIBA could be implemented using email - it isn't bound to mobile networks at all.

[Tom Jones]

that is the sort of thing that works. I am somewhat confused about the concern for sim cards. Is it because there is not a challenge response protocol? a sim is a great way for a proof of possession if done right. or do you mean the attack is just the theft of the user's smart phone?

I recently went through the process of a brazenly stolen credit card. In spite of timely reporting of the loss to the bank, the thief was able to use the card. Because we notified the police of the fraudulent use they were able to apprehend the thief. But the bank was somewhat complicit in the fraud by the glacial fraud reporting system. Somehow the theft of credentials needs to be covered in any security consideration.

[Nat Sakimura]

Please create a pull request for the proposed text.

[Joseph Heenan]

Reassigning to myself, I’ll prepare a pull request based on Dave’s suggestion.

[Joseph Heenan]

To try to respond to Tom’s most recent message:

I think the issue there is that for a bank (or other OP) to issue a challenge response that ties to a SIM card (without using SMS) is by my current understanding hard, requires a tight integration, and is not available on all mobile phone networks.

As Dave says, a sim can’t be used as the only factor, but it can potentially be used as one factor.

The currently envisaged modes of using FAPI-CIBA is that the login is as strong as happens when the user logs into the bank’s own first party app to (say) make a payment. It is not within the scope of FAPI-CIBA to dictate how a bank should secure their own app, but I understand the general current best practice is to use the Secure Enclave (to use the iOS specific language) and phone’s built in biometric authentication to give a ‘something you have’ and ‘something you are’.

In that model, if a stolen device can be used to make a payment using FAPI-CIBA, it can also be used to make a payment using the first party banking app. FAPI-CIBA itself does not introduce a new risk there.

[Joseph Heenan]

Pull request has been opened here;

‌

https://bitbucket.org/openid/fapi/pull-requests/109/ciba-add-ad-compromise-to-security/diff

‌

Prompt feedback would be greatly appreciated please given the drive to move to a draft vote ASAP.

[Joseph Heenan]

I’ve updated the text in the pull request on the basis of feedback received on this week’s call - namely that providing a non-exhaustive list of possible issues was not felt to be a direction we should go in, hence the text now just calls out that this is an issue and appropriately secure methods should be used.

[Joseph Heenan]

CIBA: Add AD security to security considerations

Add text to make clear that implementers need to consider both the security of the authentication device and the security of the communication to/from it.

closes #127

→ <<cset aa12b73ef657>>