In addition to the Display-TAN method an App-TAN method ''Display-TAN/soft'' is offered.
The method consists of a library which has the same API and the same functionality as the hardware card. Imagine Display-TAN/soft to be a soft card within the smartphone.
Display-TAN/soft is exposed to trojans, but for small value money transfers is OK - only little damage can result this way, and therefore fraudsters aren't much interested in it.
Display-TAN/soft is for bank customer who do not have the hardware Display-TAN card or those who want to have both versions. In the latter case, the two respective secret keys are of course different and independent.
Display-TAN/soft is able show more text as the smardcard version because the display of the smartphone is much larger and has more resolution. Therefore, the API for the soft version is liberalized by allowing much longer texts. This way, the soft version may be used for the confirmation of transactions which have long texts, like an address change.
Display-TAN/soft has the identical API like the Display-TAN smartcard, see below. This way, the bank does not need to add much for an existing Display-TAN implementation, or in case of a first-time implementation, there are synergy effects of up to 90%.
Display-TAN/soft may be integrated into the bank app, or it may become an extra app.
If the smartphone has a local fingerprint sensor (like iPhone) then for every transaction confirmation the FPS is automatically included.
Display-TAN/soft is delivered as a well-readable source code library, available for iOS und Android. Hardening methods are not contained, they have to be done by the bank or by a third party.
There are 2 Libraries LibDisplayTANsoftV1 und LibDisplayTANsoftV2 (each both for iOS and Android - so there are 4) corresponding to the two versions Version 1
bzw. der Version 2 of the hardware card.
In both libraries there is the following public method (in V2 it is the only one):
- (byte*) sendChallenge:(byte*) Data;
The method takes the same byte strings as input like the method with the same name within the hardware LibDisplayTAN. The return value is computed directly, and the return is returned directly - in the meantime the control is delegated to the method.
Extension: The transaction texts may be of arbitrary size (instead of exactly 10 letters), und it may contain any printable letters (besides tilda ~ which is the separation symbol). The letters may even be in Unicode or UTF-8 code: The letter are displays accordingly, while for the OCRA computation they are turned into byte strings.
Rendering is possible only with \n (new line) and \t (tab) (the two letters are part of the OCRA input-string) - some kind of higher rendering language is not planned at the moment.
In case the transaction text the format of the hardware command, in V1 the displayed text is extended with ''destination account number'' etc. (in the language of the smartphone) und is rendered appropriatly, in V2 the strings separated by ~ are displayed line by line.
- Version 1
- sendChallenge(''83507112 ~20,00~1399458665_G6HNVF'')
- sendChallenge(''Please confirm your new address:\n\tKönigsstraße 136\n\t30765 München\n\tGermany~~3973102379023'')
- Version 2
- sendChallenge(''OCRA~~123456abcXYZ~DE41~60391310 ~0757292001~EUR 8,20~ENDOCRA'')
- sendChallenge(''OCRA~~2306261461032689~Please confirm the ordering of the Display-TAN card for your account!\n\nPrice: 12.00 Euro~ENDOCRA'')
Default values. The default value for the seed in both versions V1 and V2 is ''12345678901234567890'', the default value for the AES128-key (only in V2) is ''1234567890123456''.
Setting the Credentials. In V2 the final value for the seed and the key can be set with PERSO_SETSEED~s~k~ENDPERSO (AES-encrypted), send via sendChallenge(). In V1 there is no such command.
Therefore, the following public method is added to LibDisplayTANsoftV1:
The 20-byte string S becomes the new seed after execution. The method is only executed if the current seed is the default seed. This means that the seed can be set only once - this also holds for PERSO_SETSEED~s~k~ENDPERSO in V2. Die return values for setSeed(): 0 = Success, 1 = Failure - seed was already set, 2 = Other problem.
App-ID. In V2 with the first call of the library a random 16 byte value is produced and stored. With this random App-ID (in Hex) the command PERSO_QUERYID is answered when that command is send via sendChallenge(). This way, the command PERSO_QUERYID gets an answer corresponding to the answer in the V2 hardware case..