Kaay Display-TAN
German

Display-TAN Version 2

This page is a description of the version 2 of the Display-TAN interface between bank server/smartphone and card.

Compared with version 1 we have the following extensions:

Software Extensions
  1. AES128 encryption/decryption.
    • Purpose: Defense against sniffing, for example by colleagues or neighbors. Moreover, it represents a server authentication at the card for the seed perso function.
  2. Up to 8 visualized sub-challenges can be shown to the user (instead of exactly 2).
    • Purpose: More flexibility, for example for IBAN.
    • The special case with 0 visualized sub-challenges is a challenge/response methode, for example for login without typing the OTP.
    • Any printable ASCII characters are allowed. Note that only the ones presentable with 7 segments are shown.
  3. Additional event-based OTP
    • Purpose: Login, other kinds of transactions, etc.
  4. Seed perso
    • Purpose: seed perso via Bluetooth. With it, a final seed perso of the card via the user's smartphone is possible.

Spec

General Protocol

The general protocol is the following.

Both smartphone and card are sending BLE signals that they are ready.
The bank server sends via smartphone to the card a query Q
a) if Q = ''PERSO_QUERYID'' (unencrypted), then the card executes the Query-ID Workflow;
otherwise Q is decrypted with the current AES-key to decr(Q)
b) if decr(Q) = ''OCRA~<F>~<N>~<C1>~...~<Cn>~ENDOCRA'', then the card executes the OCRA Workflow;
c) if decr(Q) = ''PERSO_SETSEED~s~k~ENDPERSO'', then the card executes the Set-Seed Workflow;
d) in any other case the card answers ''ERROR''.

card

IBAN

OCRA Workflow

1)The bank server sends via smartphone to the card the encrypted query
OCRA~<F>~<N>~<C1>~...~<Cn>~ENDOCRA
The card decrypts and will show the n sub-challenges <C1>,...,<Cn> to the bank customer successively for confirmation (the flags <F> and the nonce <N> are not shown). In case the bank customer confirms every single sub-challenge the card will generate the 8-digit TAN
2)and will send it to the smartphone as an 8-digit string.

Here is an IBAN money transfer as an example. See the image to the right what is shown and confirmed on the card.

1)smartphone to card (will be encrypted): OCRA~~123456abcXYZ~DE41~60391310  ~0757292001~EUR   98,00~ENDOCRA
2)card to smartphone: 91696086

The syntax of the <Ci>, and <N> is decribed below. But first, here is an online test interface.

Test Interface

Data string transmitted via BLE from smartphone to display card (paste a valid query):





OCRA computation steps:

1)qdata string:OCRA~~123456abcXYZ~DE41~60391310  ~0757292001~EUR   98,00~ENDOCRA
2)cencrypted data string:
(no line breaks - only inserted for presentation here)
0x2f858be773dc3920212c625776d024ee
3efeaa582fbc0497f28fd81fe3b2b7b6
d5ba43cee5a6b420da42fc18c815a19e
89191ef54cfd677bebaf33cbe4431a56
164e44c3d2e630244452b12507c7247d
3)qdecrypted data string:OCRA~~123456abcXYZ~DE41~60391310  ~0757292001~EUR   98,00~ENDOCRA
4)QSHA1(q):0x8a26c45531e3b8e015745b37dd78f4b22212e7db
5)sseed:12345678901234567890
6)TANOCRA-1:HOTP-SHA1-8:QH40 (s,Q) 91696086

Encryption

The purpose of encryption/decryption is to prevent Bluetooth sniffing when die data string is send from the smartphone to the card. Moreover, for the seed perso function PERSO_SETSEED (see below) the encryption is necessary.

The data string is encrypted by the bank server with the card's current key, i.e. individually for each card. The smartphone receives the encrypted information from the bank server and forwards it via Bluetooth to the card where it is decrypted.

The encryption/decryption algorithm is AES128 in CBC mode, the IV (Initial Vector) is fixed and consists of 16 Nulls (= 0x00). The AES key - known only to the bank server and to the card - consists of 128 bits. For demo cards the AES-key ''1234567890123456'' is used, real world cards are pre-personalized with 128 randomly chosen bits, individually for each card.

Syntax of Decrypted Challenge

A query has the following format:

OCRA~<F>~<N>~<C1>~...~<Cn>~ENDOCRA

The sub-challenges <Ci> are either of the format <I> (Info) or <A> (Amount), see below. There is no restriction on the order of both (in version 1 <I>~<A> in that order was mandatory). The number n of sub-challenges may be chosen from 0 to 8.

SubstringDescriptionSyntaxRegEx Expr.AlignmentExamples
<F>Flags<F> is usually empty and is way to specify flags. [T]{0,1}not displayedT
<N>Nonce (security protection)up to 20 printable ASCII symbols besides symbol ~ [ -}]{0,20}not displayedHdaG-353330
<I>Information1 to 10 printable ASCII letters besides symbol ~[ -}]{1,10}right aligned92283740
LoGIn
<A>Amountusually digits but all printable ASCII symbols are allowed, . or , notation, exactly 2 fractional symbols are mandatory[ -}]{0,8}(\,|\.)[ -}]{2}right aligned50.00
CHF 200,00

Note 1: In the RegEx expressions above the subexpression ''[ -}]'' means: printable ASCII symbol besides ~ (''space 0x20 to right curly bracket 0x7D''). Ok, quite technical - but short and it works!

Note 2: n=0 visualized challenges <Ci> means that only the Nonce is send to the card and the card - when it is turned on - immediately generates the TAN (because there is nothing to show to the user) and sends it back. In other words: this is just a typical challenge/response protocol (challenge = nonce) - possibly useful for some implementations.

Note 3: If <I> is to be shown left-aligned, the string has to be padded with spaces to the right.

Note 4: The only available flag at the moment is T for ''Show TAN on card''.

Seed Perso Workflow

Query-ID Workflow

(1) PERSO_QUERYID

No parameters. Server sends ''PERSO_QUERYID'' unencrypted to the card. The card sends back its ID in unencrypted ASCII. For example, the card sends back ''132873500982''. Finally, the card goes back to its base state ''--,--'', expecting to receive another message.

Set-Seed Workflow

(2) PERSO_SETSEED~s~k~ENDPERSO

2 Parameters: (1) 160-bit seed s, given as 20 Bytes. (2) 128-bit AES key k, given as 16 Bytes.

Given a message m sent to the card, m is AES128-decrypted with the currently stored AES128-key (CBC mode, IV = 0x00...00). If the decrypted message is not of the form ''PERSO_SETSEED~s~k~ENDPERSO'' and neither of the form ''OCRA~...'' (see above) the answer 'ERROR'' is returned via Bluetooth (nothing else is done on the card) and the card goes to its base state ''--,--'', expecting to receive another message.

If the decrypted message is of the form ''PERSO_SETSEED~s~k~ENDPERSO'' the following steps (1)-(5) will be executed:

  1. the preliminary seed is replaced by s,
  2. the preliminary AES128-key is replaced by k,
  3. the internal flag ''PERSO_ON'' is set from 1 (default at production) to 0.
  4. the message ''PERSO_SUCCESS'' is returned via Bluetooth to the sender,
  5. the card goes to its base state ''--,--'', expecting to receive another message.

Both functions PERSO_QUERYID and PERSO_SETSEED will answer from now on (i.e., when PERSO_ON == 0) the message ''PERSO_DONE'' to all queries. In other words, the perso interface is turned off once and for all.

Example of a decrypted message: ''PERSO_SETSEED~...~...~ENDPERSO''. The first dots represent 20 Bytes, the other dots represent 16 Byte.

During the execution of PERSO_QUERYID or PERSO_SETSEED still ''--,--'' is shown on the card's display - in a blinking way so that the user notices activity. Blinking is preferred in heart beat fashion, i.e. once a second: 100ms not shown, 900 ms shown, etc.. (Without showing text, the personalisation can fully be hidden from the user. If the bank wants to inform the user it can do this on the smartphone's display).

The ''OCRA~...'' commands and the OTP will work even if the card is not finally personalised (i.e., when PERSO_ON == 1), via the preliminary seed and key. (This may be useful if for example some bank considers the pre-personalisation to be sufficently secure).

Event-based OTP

With a second click on the OK button on the card (being in base state ''--,--'') the user will be shown an event-based 6 digit OCRA OTP, produced with the current OCRA seed. The purpose of this mode is to offer a second factor for other purposes, like login or transactions having too long texts.

The counter for the OTP is initialized at production with 000000 and is incremented +1 everytime the card is turned on. The seed for the OTP generation is the current OCRA seed. The OCRA Suite is OCRA-1:HOTP-SHA1-6:QA06.

When the OK button is pressed again in that state, the card turns off.

Links

More InformationDemo AppsAPIMore FunctionalitiesLinksContact
Workflows
IBAN
Comparison with App-TAN
More Information
Friendly Fraud
PSD2-Compliance
Business Partners
Android App
iOS App
API Version 1
API Version 2
SDK/Library
Display-TAN/soft
Seed Perso
Display-PIN
Online Banking Demo
IoT Applications
nfc-tan.com
smartdisplayer.com
borchert-it-sicherheit.com
YouTube Playlist ''Technology Cards''
About
Contact
Imprint