4
$\begingroup$

ISO 9564-1 format 4 describes an extended PIN block format. Simply said, this standard can be used to encrypt 4-digit PIN codes in a secure way.

The standard mentions (simplified) to add random values to the PIN, before encrypting it with a cipher that can be chosen by the implementer (we will go for AES-CTR).

I wonder now, if we follow this standard, and append a cryptographically random value to the PIN before encryption, do we then still need an IV for the AES encryption?

$\endgroup$
0

3 Answers 3

3
$\begingroup$

Without access to the standard I cannot verify, but prefixing a random value won't influence the output of the ciphertext of the PIN when using AES-CTR. So yes, you'd need an IV.


Prefixing a value may or may not influence the ciphertext of the PIN itself produced by the mode of operation. For AES-CBC this is certainly the case as the ciphertext block itself is used as a vector for the next operation. For AES-CTR this is however not the case; the random value will just be encrypted by XOR'ing it with the key stream.

It seems that either the standard would want you to choose a specific block cipher or that it is simply incorrect. Prefixing or appending anything to the PIN doesn't do anything for you if counter mode encryption is used.


Prefixing a (16 byte) random IV to the ciphertext however does make sense. You need at least a unique value for each PIN; if the encryption is deterministic (i.e. is only calculated using the PIN) then an attacker will (at least) be able to distinguish identical PIN numbers; there are often only 10000 values - or less if some PIN values are excluded - to choose from.


For reference I'll include a picture of the CTR mode of operation:

enter image description here

As you can see you need to change the nonce/counter value to influence the ciphertext for a particular plaintext. Prefixing or appending any value to the plaintext message won't make a difference.

For instance, replace the first plaintext block with an IV value, you can see that the second block is not changed at all as the blocks of plaintext / ciphertext are completely independent. And if you consider the XOR operation you can even deduce that each bit of plaintext/ciphertext is completely independent of the other one (unless the cipher is broken).

This is why prefixing / appending a value to the plaintext won't act as an IV in itself.

$\endgroup$
7
  • $\begingroup$ Thanks for your answer. I don't fully get your last paragraph: it seems to contradict the other paragraphs. Prefixing/appending an IV might make sense in AES-CBC, but it won't probably make any sense when using AES-CTR. That is clear. However, in the last paragraph you seem to suggest that prefixing a random value does make sense, or do you mean 'adding' instead of 'prefixing'? $\endgroup$
    – Michael
    Feb 13, 2017 at 12:18
  • $\begingroup$ There is a difference between prefixing any random value and prefixing the IV used for the mode of operation. The former is not what you want but as the IV can be public there is no reason why you could not prefix it (or store it otherwise with the ciphertext). Does this clear it up? $\endgroup$
    – Maarten Bodewes
    Feb 13, 2017 at 12:20
  • $\begingroup$ Partially: why would it make sense to do that in AES-CTR? As you explain in the other paragraphs, this IV will then just be XOR'ed with the key stream. If we assume that the key stream is based on the key and the IV, and that the IV is sent along with the cipher text, what would be the sense of prefixing the IV with the plain text? $\endgroup$
    – Michael
    Feb 13, 2017 at 12:26
  • $\begingroup$ A random value added (concatenated) to the PIN will NOT act as an IV, this is what I'm trying to tell you. The IV in CTR mode is used as initial value for the counter. $\endgroup$
    – Maarten Bodewes
    Feb 13, 2017 at 12:28
  • $\begingroup$ Yes, that's why I do not understand the sentence "Prefixing a (16 byte) random IV however does make sense", or did you not mean anything with it specifically? $\endgroup$
    – Michael
    Feb 13, 2017 at 12:36
4
$\begingroup$

ISO 9564-1 format 4 does not need a IV since it adds entropy to the plaintext PIN before encrypting. There is no need to append a random value to the PIN.

Diagram of ISO 9564-1 Format 4 Encryption

The Format 4 PIN block algorithm is illustrated above. The PIN and the PAN are both padded. The padded values are called the plain text PIN field and the plain text PAN field. The last $8$ bytes of the padded PIN field are random. The plain text PAN has deterministic padding. The plain text PIN field is encrypted and then XORed with the plain text PAN field and the result is then encrypted again, yielding the encrypted PIN block.

Format 4 is typically used with a fixed AES key for each encryption operation on a particular device. Since there are only $8$ bytes of mixed-in entropy for each PIN-PAN combination, Format 4 has the potential to be vulnerable to a chosen plaintext dictionary attack. An attacker could capture an encrypted Format 4 PIN Block. The attacker could then recover the PIN by repeatedly encrypting all possible PIN values until by chance the encrypted PIN block is the same as the encrypted PIN block the attacker is attempting to decode.

There are $64$ bits of random data in the plain text PIN Block. The PIN is between $4$ and $12$ decimal digits and thus adds at least $13$ bits of entropy. Therefore above attack would require at least $2^{77}$ chosen plaintexts.

It would difficult to obtain $2^{77}$ chosen plaintexts from any single device. Furthermore, the PCI PTS standard requires compliant devices to rate limit PIN encryption to $120$ PINs per hour. As such, the above attack is not feasible.

$\endgroup$
2
  • $\begingroup$ Thank you, your answer might be correct when using block ciphers, however, when using AES CTR I think Maarten Bodewes' answer is the only correct one. $\endgroup$
    – Michael
    Feb 21, 2017 at 5:46
  • 1
    $\begingroup$ ISO 9564-1 format 4 requires the use of ECB. If you use any other block cipher mode, you are not using ISO 9564-1 format 4. $\endgroup$ Feb 21, 2017 at 6:06
3
$\begingroup$

ISO 9564-1 section 6.2 says use one of the algorithms in 9564-2 Approved algorithms for PIN encipherment, which for block 4 the only Approved one is AES ECB (hence no IV).

$\endgroup$
3
  • $\begingroup$ Yeah, that would explain a lot. Even for an 8 bit block cipher such as (triple) DES you'd still have 48 bits of randomness per PIN. $\endgroup$
    – Maarten Bodewes
    Feb 13, 2017 at 20:19
  • $\begingroup$ I'm gonna purchase 9564-2. However, 9564-2 dates from 2014, and the amendment to 9564-1 (which added format 4 to make it easier to use with AES encryption algorithms) dates from 2015. Btw, isn't ECB pretty insecure? $\endgroup$
    – Michael
    Feb 14, 2017 at 6:39
  • $\begingroup$ You are right, it prescribes ECB. This would make me even more reluctant to adhere to the standard, as ECB should be a no-go (at least that's what I thought). $\endgroup$
    – Michael
    Feb 21, 2017 at 5:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.