Hide last authors
Pål-Eirik Askerød 1.2 1 == Key schemes ==
Pål-Eirik Askerød 1.1 2
Bjørnar Ruud 18.2 3 PayEx support fixed H2H Shared keys for MAC, PIN and Data Encryption or a ZKA scheme.
Pål-Eirik Askerød 1.1 4
Bjørnar Ruud 18.2 5 This fixed key solution defines three different keys which are shared with the 3rd party that integrates the PayEx H2H IFSF protocol.
Pål-Eirik Askerød 1.1 6
Bjørnar Ruud 18.2 7 The ZKA scheme defines a master ZKA key used to derive an Pin and Mac key unique per transaction. The data encryption key is used the same way as the fixed key solution.
Pål-Eirik Askerød 1.1 8
9
Kristian Lingsom 6.1 10 == Test keys ==
Pål-Eirik Askerød 5.3 11
Kristian Lingsom 10.1 12 | |=H2H Key version|=Component 1 |=KCV |=Component 2 |=KCV|=Total Key KCV
Pål-Eirik Askerød 20.1 13 |Encryption Key|0100|7686 D6CB 708F 2319 108A 7AB6 9E8C 64161 |B7DB 1260|2D30 6353 8E47 C074 6A9F AA53 84C9 3F0A |25B5 7BF7|4C12B4
14 |MAC Key |0100|07C8 A734 29BA 2A437C76 C8BC 4551 7607 |6224 DE35|AC1E CA72 9927 7D74 ED65 EED4 0065 097B |6320 95D1 |7CC660
15 |PIN Key |0100|F210 F201 7A3E 3D89 20D9 B53D 1C49 13EF |10EC E3C4|7133 9066 2BF9 5F8D 2863 D2B4 1E17 7D5C |F116 767E|866C07
16 |ZKA Key |0200|F210 F201 7A3E 3D89 20D9 B53D 1C49 13EF |10EC E3C4|7133 9066 2BF9 5F8D 2863 D2B4 1E17 7D5C|F116 767E |866C07
17 |ZKA Data Encryption Key|0200|7686 D6CB 708F 2319 108A 7AB6 9E8C 64161 |B7DB 1260|2D30 6353 8E47 C074 6A9F AA53 84C9 3F0A |25B5 7BF7|4C12B4
Pål-Eirik Askerød 5.3 18
Kristian Lingsom 8.1 19 **Procedure to create complete keys:**
Kristian Lingsom 11.1 20 Component1 Xor Component2 = key. Then copy the first 8 bytes of key to the end of key to a total of 24 bytes.
Pål-Eirik Askerød 5.3 21
Kristian Lingsom 8.1 22 **Check key against total KCV.**
23 Create 8 byte array with zero bytes and encrypt with Triple-DES ECB and compare 4 first bytes to total KCV. If they match key is genereated correctly
Pål-Eirik Askerød 5.3 24
Pål-Eirik Askerød 4.5 25 == Security Related Control Information ==
Pål-Eirik Askerød 1.1 26
Pål-Eirik Askerød 4.11 27 This information is transported in field P-53 towards PayEx Host. **For scheme H2H Shared keys only 53-1 needs to be populated with the version of keys**.
Pål-Eirik Askerød 1.1 28
Kristian Lingsom 5.1 29 This field (53-1) needs to be present in all request that have MAC, PIN or encrypted data. Field P-53 is binary with LLVAR length.
Pål-Eirik Askerød 1.1 30
Pål-Eirik Askerød 1.2 31 |=Element|=Name|=Format|=Attribute|=Description
32 |53| |n|2|LLVAR length field
Pål-Eirik Askerød 21.1 33 |53-1|H2H Key version|b|2|Version of keys shared by PayEx with 3rd party. E.g "0100" when using the test keys or "0200" when using ZKA keys
Bjørnar Ruud 15.2 34 |53-2|MAC random value|b|16|(((
35 ZKA MAC random value.
Pål-Eirik Askerød 1.2 36 )))
Bjørnar Ruud 15.2 37 |53-3|PAC random value|b|16|ZKA PAC random value.
Pål-Eirik Askerød 1.2 38
Pål-Eirik Askerød 4.5 39 **PayEx shared key scheme**
Pål-Eirik Askerød 4.3 40
Pål-Eirik Askerød 4.9 41 PayEx supplies key version to be sent in 53-1. This scheme defines 3 different keys for MAC, PIN and Data encryption which will be shared between PayEx and 3rd party.
Pål-Eirik Askerød 4.3 42
Bjørnar Ruud 15.2 43 **ZKA scheme **
Pål-Eirik Askerød 4.5 44
Bjørnar Ruud 15.2 45 PayEx supplies key version to be sent in 53-1. Note that a set of different values are defined for both test and production. Also values are unique for every third party (host).
Pål-Eirik Askerød 4.5 46
47 For optimal security it is a good practice to use different random values for the MAC and PAC. However the security impact of having the same random number for PAC and MAC is very limited. Especially because in the MK/SK security scheme an XOR of the Master key with a fixed Control Mask is done, where the Control Mask value is different for PIN and MAC. So even if the MAC session key would be compromised the PIN session key still cannot be determined even when the same random number is used. It is important to assure that different random numbers are used for every transaction.
48
49 == Message Authentication Code (MAC) ==
50
Bjørnar Ruud 12.2 51 We use ISO/IEC 9797-1 MAC algorithm 3 also known as Retail Mac.
Pål-Eirik Askerød 4.3 52
Pål-Eirik Askerød 4.12 53 PayEx uses a double-length key. (128 bit)
Pål-Eirik Askerød 4.3 54
Pål-Eirik Askerød 4.5 55 The input for the MAC calculation/verification will be the SHA-256 of the IFSF message. The message length header and the MAC block itself are not included, however the MAC bit in the bitmap is part of the message and is already set when calculating the MAC.
Pål-Eirik Askerød 4.3 56
Pål-Eirik Askerød 4.5 57
Pål-Eirik Askerød 4.3 58 ==== Mac calculation method: ====
59
60
Bjørnar Ruud 12.2 61 [[image:3-Figure1-1.png||height="382" width="608"]]
Pål-Eirik Askerød 4.3 62
63
Bjørnar Ruud 12.2 64 ~1. The incoming message is padded with 0x00 until the message length is multiple of 8 bytes.
65 2. The 128 bit key is divided into two sub-keys. Left part is called K,,1,,, and right part K,,2,,.
66 3. Data is encrypted as DES CBC with K,,1,,
67 4. Take the last blocks output data and DES encrypt again with K,,1,,
68 5. Take the output data and decrypt DES with K,,2,,
69 6. Take the output data and encrypt DES with K,,1,,
Bjørnar Ruud 17.1 70 7. For ZKA MAC use the 8 bytes of output data as MAC. For fixed key MAC take the first 4 bytes of output data and pad with 0x00 again to 8 bytes.
Pål-Eirik Askerød 4.3 71
Bjørnar Ruud 12.2 72
Pål-Eirik Askerød 4.5 73 ==== Transport of MAC ====
Pål-Eirik Askerød 1.2 74
Pål-Eirik Askerød 4.11 75 MAC value is transported in P-64 or P-128 towards PayEx. P-128 is used when P-127 is present. Field is binary with a length of 8.
Pål-Eirik Askerød 4.5 76
77 == Personal Identification Number (PIN) ==
78
Pål-Eirik Askerød 4.7 79 Pin enciphered block is transported in P-52 towards PayEx. Format is binary, length 8.
Pål-Eirik Askerød 4.5 80
Pål-Eirik Askerød 4.14 81 PIN-block format is ISO-0 (same as ANS X9.8, VISA-1, and ECI-1).
82
Pål-Eirik Askerød 4.7 83 Pin encryption key must be used to encrypt pin block sent to PayEx.
Pål-Eirik Askerød 4.5 84
85
Pål-Eirik Askerød 4.4 86 ==== PIN Encryption Methodology ====
87
Pål-Eirik Askerød 1.2 88 This information is transported in P-48.14 field towards PayEx Host.
89
90 |=Element|=Name|=Format|=Attribute|=Description
91 |48| |n|3|LLLVAR length field
Pål-Eirik Askerød 4.13 92 |48-14|PIN Encryption Methodology|ans|2|Identifies the PIN encryption scheme used for pin block encryption. Supported values listed below.
Pål-Eirik Askerød 1.2 93
94 ‘13’: PayEx H2H shared keys
95
Bjørnar Ruud 16.1 96 ‘33’: ZKA MS/SK PAC H2H
Pål-Eirik Askerød 1.2 97
98 When P-52 is present in request, this field must also be present. When field P-52 is NOT present, field 48-14 should also NOT be present.
99
Pål-Eirik Askerød 4.5 100 PayEx H2H shared key scheme defines a pin encryption key that is used to encrypt the pin block.
Pål-Eirik Askerød 1.2 101
Pål-Eirik Askerød 4.6 102
Bjørnar Ruud 14.1 103 ==== Data encryption ====
104
Pål-Eirik Askerød 4.6 105 Encrypted card data (track2) is transported in P-127 field towards PayEx. Format is LLLBinary
106
Pål-Eirik Askerød 4.8 107 Data must be encrypted with Triple-DES CBC mode using the data encryption key provided by PayEx.
Pål-Eirik Askerød 5.2 108
109 This field has TLV format.
110
111 Tag (3 hex chars) is field number in BCD. Eks: P-35='035'
112
113 Length (2 hex chars) is the length of the data field in hex.
114
115 Value encrypted field value in hex
116
117 Complete TLV data is packed to binary and padded to a multiple of 8 bytes.
118
119 Track2 eksempel in hex:
120
121 035257071557105754509915D19034000040000000F00000 (24 bytes)
122
123 Tag: 035
124
125 Length: 25x = 37
126
127 Value: 7071557105754509915D19034000040000000
128
129 Padding: F00000 ( Padding contains an end sentinel)