Table of Contents

ADUCID Binding

Binding is a new, ADUCID-controlled functionality. It is used to protect data channel between client and application.

There are several binding types derived from the use scenarios of the target application, ADUCID means (PEIG types) and technological limits.

The following binding types are currently designed:

Name Description Communication
A application binding using PEIG on the same host that the application client is running App-PEIG communication uses http redirect to local host port 44240 and A1R (application, one device, redirect).
B application binding using PEIG on the same host that the application client is running App-PEIG communication uses URI schema (Android) and A1U (application, one device, URI).
C application binding using PEIG on a different host than the application client is running App-PEIG communication uses QR code and A2Q (application, two devices, QR).
D1 application binding using PEIG on a different host than the application client is running (two devices) App-PEIG communication uses a QR code displayed by PP (switched-off PEIG (red button)). The host with the target application includes ADUCID client software (PEIG). App-PP communication uses RA, PP-PEIG communication uses QR code and A2RQ (application, two devices, redirect, QR).
D2 application binding using PEIG on a different host than the application client is running (two devices) App-PEIG communication uses a QR code displayed by PP (PEIG sign-in OFF). The host with target application includes ADUCID client software (PEIG). App-PP communication uses URI schema, PP-PEIG communication uses QR code—A2UQ (application, two devices, URI, QR).
E TLS binding using PEIG on the same host as the application client is running TLS-PEIG communication uses internal call with URI (beta functionality—not supported in ADUCID 3.1) —T1U (TLS, one device, URI).
F TLS binding using PEIG on a different host than the application client is running TLS-PEIG communication uses QR code (beta functionality — not supported in ADUCID 3.1) — T2Q (TLS, two devices, QR).
G TLS binding with PEIG on another host than client of the target application (two devices) communicates with TLS-PEIG using code displayed by PP. On host with TLS is SW ADUCID (Peig - deactivated). Communication TLS-PEIG using QR code – T2Q (TLS, 2device, QR)

PEIG (PP) evaluates information about the communication path used (input from the application), and then transfers the information to AIM by specific binding communication over the R3 interface.

AIM controls communication during the operation start, based on the information received from PEIG (PP). AIM evaluates the information about binding communication, about PEIG activity and controls binding (with respect to the binding settings). AIM transfers information about the binding used to the target application, as a part of the PSL attributes.

Application binding global schema

Binding design A—A1R

Classical binding is used in older ADUCID versions. Redirect Adapter and PEIG are used on the same personal computer as the target client part of the application.

It is extended by using bindingId and bindingKey to control binding, and to support compatibility with other binding scenarios.

Binding A—A1R

Binding design B—A1U

The new binding using URI schema aducid: enables communication between the target application client, such as a Web browser, and the ADUCID client (PP, PEIG). It is developed to be used in mobile phone operating systems, especially (Android, iOS). It can be used in modern workstations as well. Compared to binding A—A1R, it eliminates the risks of communication between different user contexts in multiuser systems, due to the elimination of use of shared TCP/IP Redirect Adapter port. It requires administrator rights for URI schema registration.

Binding B—A1U

Binding design C—A2Q

There is a new binding that uses a QR code, without the need to install any specific ADUCID client software on a client workstation. The QR code is displayed directly by the target client application (web browser). The security threats reflect the scenario.

Note: Threats can be solved by usage of secure transaction confirmation (use of ADUCID personal objects).

Binding C—A2Q

Binding design D—A2RQ and A2UQ

This is new specific solution of QR code use.

The more secure option of C (A2Q) is a design target in this case. A faked active MITM site displaying the QR code and mimicking client to a target application should be eliminated in this case.

PP creates an encrypted, unauthenticated channel between PP and AIM during the first part of binding communication, by using a temporary asymmetric key pair—ppPrivKey and ppPubKey. The UCP tools are used to support a creation and transfer of shared session key X.

The channel is used to transfer all required information for binding control, including the return URI of the target application (returnUrl).

PP creates two keys (ppBindingKey = hash(X, ppPubKey, returnUrl) and ppAuthKey = hash(X, ppPubKey).

PP transfers ppBindingKey to PEIG as bindingKey in the QR code.

PP waits for authentication to end, by using binding wait communication with AIM.

When the QR code is scanned by PEIG, and PEIG starts its communication with AIM, the QR code is cleared by PP, to decrease risk of rescanning the QR code and related authentication failure caused by repeated use of authId. PEIG authenticates the user and secures the binding channel during its operation.

PP redirects the user to the return URL, including transfer of the ppAuthKey as AuthKey in the return message.

Security note:

Waiting communication between PP and AIM is not cryptographically protected (using S(Y) and S(Z)). The risks are acceptable and protection should bring additional issues. The risks have a Denial of Service (DoS) nature (e.g. early QR code clearing, early redirection to returnUrl). The possible attacks in cryptographically protected communications should cause events generating a DoS, as well.

Binding D—A2RQ and A2UQ

Provider’s scenarios


Supported scenarios
Binding Mode
Description

ABCD
0
All possible options, weak and strong binding (A—A1R, B—A1U, C—A2Q, D—A2RQ, A2UQ)

ABD
1
One or two devices, strong binding (A—A1R, B—A1U, C—A2Q, D—A2RQ, A2UQ)

ACD
2
1+1 only (two devices or token and device), weak and strong binding, single user workstation (A—A1R, C—A2Q, D—A2RQ, A2UQ)

AB
3
One device only (A—A1R, B—A1U)

AC
4
1+1 only (two devices or token and device), no software installation on client workstation is required, weak binding, single user workstation (A—A1R, C—A2Q)

AD
5
1+1 only (two devices or token and device), strong binding, single user workstation (A—A1R, D—A2RQ, A2UQ)

BCD
6
All for a multiuser workstation, weak and strong binding (B—A1U, C—A2Q, D—A2UQ)

BD
7
All for a multiuser workstation, strong binding (B—A1U, D—A2UQ)

B
8
Only one mobile phone or tablet (B—A1U)

CD
9
Only two devices, weak and strong binding (C—A2Q, D—A2RQ, A2UQ)

C
10
Only two devices, without installation on a workstation (C—A2Q)

D
11
Two devices, with strong binding only (D—A2RQ, A2UQ)

Cs
12
Only two devices, without installation on workstation, simplified QR code – without bindingKey (C—A2sQ)

Note: TLS scenarios (E – T1U and F – T2Q) are not included in this list. They are not supported in ADUCID 3.1.

Client ADUCID software (PEIG without identity) installation on workstation is required for B and D scenarios. Scenario C does not require software installation. Excluded scenarios (mathematically possible):