NECP only requires keys to generate MACs. Encryption is not a function of NECP. In the case of Shopping Cart Orders, encryption is not required. In the case of Cardholder Orders, the SSL encryption layer of the acquirer’s web server is relied upon to provide the data encryption function.

NECP uses a 16 byte symmetrically key generated by a cryptographic grade pseudo random number generator. A key of this size allows for 3.4E38 possible combinations. A brute force attack testing 1 million keys a second would still require 1.1E22 millennia to try all combinations.

The management of key generation is important to the security of the protocol. This importance is best illustrated given some hypothetical scenarios:

• A key is used to generate MACs for a merchant. This merchant is a particularly active one and a malefactor is able to sniff all transactions from the merchant to the acquirer. Given sufficient volumes and time, the malefactor is able to reverse engineer the key used to generate the MACs. Replacing MAC keys on a regular basis would mitigate this form of attack.
• An employee of the merchant’s hosting company terminates her employment. She has knowledge of the MAC generation key. She then takes this key and sets up a spoofing site to embarrass her former employer. Allowing the employer to “sunset” a current key and obtain a fresh key would foil this form of attack.
• The merchant moves its electronic storefront to a new hosting provider. The merchant wants to severe all ties with its former hosting provider. Allowing the merchant to sunset a current key and obtain a fresh key would protect the merchant.

The key generation function is supplied by the acquirer using an SSL encrypted web enabled interface. To obtain a key on behalf of a merchant, the merchant’s username and password must be supplied to the key generator.

If this is not the first key generated for the merchant, then the requester must supply some knowledge of the most recent former key, such as the first four bytes. In this way, the requester must demonstrate knowledge available only to the merchant as well as demonstrate knowledge of the merchant’s current environment.[1]

At the time of requesting a new key, the requester can also request the period to expire the previous key. If this were a routine key change, then some default period such as one week would allow for the merchant to operate using either key during this interim period. If this is a security-related change, then the current key can be expired immediately.

The new key value and its serial number along with the expiration date of the current key are stored by the acquiring system in its database. The new key’s value and serial number and a confirmation of the expiration of the old key are returned to the requester.