Relative merits of AES ECB and CBC modes for securing data at rest I need to store several million Payment Card Numbers (PCNs) securely in a mainframe database (that is, 'at rest'). I assume that any attacker will have access to all of the stored data.

I assume the availability of a secure device that can:


Store a unique, constant ('master') key that is to be used for all
PCNs
If necessary, store a unique, constant IV to be used for all
encryption with the master key
Encrypt (AES-256) data in ECB or CBC mode
Decrypt (AES-256) data in ECB or CBC mode


What are the relative merits and demerits of the following possible options for encryption and decryption?:


Use the master key in ECB mode. I have heard/read that this is
cryptographically weak (Why?).
Use the master key and IV in CBC mode.
Prepend a 16-byte, microsecond-or-finer, timestamp to the PCN, then use the master key and IV in CBC mode. This would mean storing an additional 16-byte block of ciphertext, but this isn't a problem. On decryption, just discard the first 16 bytes of the resulting plaintext.
(If available) As (3), but have the device provide a 16-byte pseudo-IV.
Something better (please specify)


Extra kudos for explaining possible attacks on a large quantity of sixteen-digit numbers encrypted under any of these schemes. 

I'm new at this, and I know it's very easy for noobs to produce stuff that an average cryptologist would find laughable, so please be gentle -- I'm just trying to learn.

I've placed this here, rather than on security.SE, because it looks like a better fit; if y'all disagree, I shall be most grateful if you will migrate it, rather than closing as off-topic.



For additional clarification, following the answer from @curious :

The reason I include ECB mode here is that it could allow me to save half the storage space. Since the messages are only one block long, I suspect this may affect the 'traditional' arguments against ECB.

But I am interested in understanding whether there are any specific vulnerabilities arising from:


The relatively low entropy of the messages (message space of 1E16 possibilities, reduced by PCN checksums)
The use of a fixed, universal key or key+IV
While I'll try to answer your question at a theoretical level below, I'd like to first stress the following:  It's a bad sign if, in the course of writing software, one is making such low-level decisions about encryption methods.  Encryption security is extremely brittle, with seemingly insignificant details causing complete failure.

With that said, the question brings up some interesting issues with encryption security versus efficiency.

As the other answer notes, ECB reveals when the same block has been enciphered twice and CBC does not (as long as the IV is unique or random).  If you are, for some reason, absolutely sure the same block will never be enciphered, then ECB is in theory fine.  (One technique might be to encipher the blocks in "batches" using a wide-input blockcipher, so that now a ciphertext will repeat only if an entire "batch" repeats.)  But in my opinion this is an unnecessary risk.

Will you ever change blocks of the data once it is written?  This need is one of the distinguishing requirements when dealing with "data at rest" (as opposed to e.g. data being sent over an SSL connection).  ECB, while insecure, will allow you to efficiently change the data in place while CBC will not.  But be aware that the security your are achieving in either case is not ideal.

In general, and especially if local updates are needed, a better technique is to employ a "tweakable block cipher" with the disk location as the tweak.  This will hide repeats amongst different blocks if one uses the block's index (disk location, etc) as the "tweak."  Moreover, it will allow for efficient updates.  This can be combined with the "batching" technique above to provide a level of security that seems pretty strong:  A repeat will only be noticed by an adversary who can watch you change the data, and only when you write the same batch of numbers to the same location twice.  Otherwise the data will be kept private in a strong sense.

It might be help to look at the IEEE 1619 standards documents and associated references for information about tweakable blockciphers and the wide-input batching technique.  The theory outlined there is a long way from a "secure" implementation, and again it seems you probably want to use an existing implementation of this stuff rather than roll own.