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?
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:
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.
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.
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.
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).
