8. CBC-DES Symmetric Encryption Protocol

This section describes the CBC-DES Symmetric Encryption Protocol. This protocol is the first privacy protocol defined for the User-based Security Model.

This protocol is identified by usmDESPrivProtocol.

Over time, other privacy protocols may be defined either as a replacement of this protocol or in addition to this protocol.

8.1. Mechanisms

The CBC-DES encryption protocol provides the following mechanisms:

Data Confidentiality Support

In support of data confidentiality, an encryption algorithm is required. An appropriate portion of the message is encrypted prior to being transmitted. The User-based Security Model specifies that the scopedPDU is the portion of the message that needs to be encrypted.

Secret Value and Timeliness

A secret value in combination with a timeliness value is used to create the en/decryption key and the initialization vector. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user.

8.1.1. Symmetric Encryption Protocol

The Symmetric Encryption Protocol defined in this memo provides support for data confidentiality. The designated portion of an SNMP message is encrypted and included as part of the message sent to the recipient.

Two organizations have published specifications defining the DES:

The National Institute of Standards and Technology (NIST) DES-NIST
The American National Standards Institute DES-ANSI

There is a companion Modes of Operation specification for each definition (DESO-NIST and DESO-ANSI, respectively).

8.1.1.1. DES key and Initialization Vector

DES Key

The first 8 octets of the 16-octet secret (private privacy key) are used as a DES key. Since DES uses only 56 bits, the Least Significant Bit in each octet is disregarded.

Initialization Vector (IV)

The Initialization Vector for encryption is obtained using the following procedure:

Step 1: Pre-IV

The last 8 octets of the 16-octet secret (private privacy key) are used as pre-IV.

Step 2: Salt Generation

In order to ensure that the IV for two different packets encrypted by the same key, are not the same (i.e., the IV does not repeat) we need to "salt" the pre-IV with something unique per packet. An 8-octet string is used as the "salt".

The concatenation of the generating SNMP engine's 32-bit snmpEngineBoots and a local 32-bit integer, that the encryption engine maintains, is input to the "salt". The 32-bit integer is initialized to an arbitrary value at boot time.

Step 3: Salt Encoding

The 32-bit snmpEngineBoots is converted to the first 4 octets (Most Significant Byte first) of our "salt". The 32-bit integer is then converted to the last 4 octet (Most Significant Byte first) of our "salt".

Step 4: IV Calculation

The resulting "salt" is then XOR-ed with the pre-IV to obtain the IV.

Step 5: privParameters

The 8-octet "salt" is then put into the privParameters field encoded as an OCTET STRING. The "salt" integer is then modified. We recommend that it be incremented by one and wrap when it reaches the maximum value.

Implementation Note:

How exactly the value of the "salt" (and thus of the IV) varies, is an implementation issue, as long as the measures are taken to avoid producing a duplicate IV.

The "salt" must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt the message.

8.1.1.2. Data Encryption

The data encryption process follows these steps:

Step 1: Padding

The data to be encrypted is treated as sequence of octets. Its length should be an integral multiple of 8 - and if it is not, the data is padded at the end as necessary. The actual pad value is irrelevant.

Step 2: Cipher Block Chaining Mode

The data is encrypted in Cipher Block Chaining mode.

Step 3: Block Processing

The plaintext is divided into 64-bit blocks.

The plaintext for each block is XOR-ed with the ciphertext of the previous block, the result is encrypted and the output of the encryption is the ciphertext for the block. This procedure is repeated until there are no more plaintext blocks.

Step 4: First Block

For the very first block, the Initialization Vector is used instead of the ciphertext of the previous block.

8.1.1.3. Data Decryption

The data decryption process follows these steps:

Step 1: Length Verification

Before decryption, the encrypted data length is verified. If the length of the OCTET STRING to be decrypted is not an integral multiple of 8 octets, the decryption process is halted and an appropriate exception noted. When decrypting, the padding is ignored.

Step 2: First Block Decryption

The first ciphertext block is decrypted, the decryption output is XOR-ed with the Initialization Vector, and the result is the first plaintext block.

Step 3: Subsequent Blocks

For each subsequent block, the ciphertext block is decrypted, the decryption output is XOR-ed with the previous ciphertext block and the result is the plaintext block.

8.2. Elements of the DES Privacy Protocol

This section contains definitions required to realize the privacy module defined in this section of this memo.

8.2.1. Users

Privacy using this privacy protocol makes use of a defined set of userNames. For any user on whose behalf a message must be en/decrypted at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.

A user and its attributes are defined as follows:

`<userName>`

A string representing the name of the user.

`<privKey>`

A user's secret key to be used when en/decrypting messages. It MUST be 16 octets long for CBC-DES.

8.2.2. msgAuthoritativeEngineID

The msgAuthoritativeEngineID value contained in an authenticated/encrypted message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document RFC 3411).

The user's (private) privacy key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the en/decryption process.

8.2.3. SNMP Messages Using this Privacy Protocol

Messages using this privacy protocol carry a msgPrivacyParameters field as part of the msgSecurityParameters.

For this protocol, the msgPrivacyParameters field is the serialized OCTET STRING representing the "salt" as described in section 8.1.1.1.

8.2.4. Services Provided by the DES Privacy Module

This section describes the inputs and outputs that the DES Privacy module expects and produces when the User-based Security module calls the DES Privacy module for services.

8.2.4.1. Services for Encrypting an Outgoing SNMP Message

The DES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used.

Upon completion the privacy module returns statusInformation and, if the encryption process was successful, the encryptedPDU.

The abstract service primitive is:

statusInformation =              -- success or failure
  encryptData(
  IN   privKey                   -- secret key for encryption
  IN   dataToEncrypt             -- scopedPDU to be encrypted
  OUT  encryptedData             -- encrypted scopedPDU
  OUT  privParameters            -- serialized "salt" value
       )

Parameters:

statusInformation: An indication of whether the encryption process was successful. If not it is an indication of the problem.
privKey: The secret key to be used by the encryption algorithm. The length of this key MUST be 16 octets.
dataToEncrypt: The scopedPDU to be encrypted.
encryptedData: The encrypted scopedPDU on output.
privParameters: The "salt" value used for this encryption, to be sent in msgPrivacyParameters.

8.2.4.2. Services for Decrypting an Incoming SNMP Message

The DES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used.

Upon completion the privacy module returns statusInformation and, if the decryption process was successful, the decryptedPDU.

The abstract service primitive is:

statusInformation =              -- success or failure
  decryptData(
  IN   privKey                   -- secret key for decryption
  IN   privParameters            -- as received in msgPrivacyParameters
  IN   encryptedData             -- encrypted scopedPDU
  OUT  decryptedData             -- decrypted scopedPDU
       )

Parameters:

statusInformation: An indication of whether the decryption process was successful. If not it is an indication of the problem.
privKey: The secret key to be used by the decryption algorithm. The length of this key MUST be 16 octets.
privParameters: The "salt" value received in msgPrivacyParameters.
encryptedData: The encrypted scopedPDU to be decrypted.
decryptedData: The decrypted scopedPDU on output.

8.3. Elements of Procedure

This section describes the procedures for the CBC-DES privacy protocol.

8.3.1. Processing an Outgoing Message

This section describes the procedure followed by an SNMP engine when it generates a message with privacy (encryption) on behalf of a user.

Step 1: Obtain Privacy Key

Obtain the 16-octet privKey for the user.

Step 2: Extract DES Key

Extract the first 8 octets as the DES key.

Step 3: Obtain Pre-IV

Extract the last 8 octets as the pre-IV.

Step 4: Generate Salt

Generate an 8-octet salt value using snmpEngineBoots and a local counter.

Step 5: Calculate IV

XOR the salt with the pre-IV to get the Initialization Vector.

Step 6: Pad Data

Pad the scopedPDU if necessary to make it a multiple of 8 octets.

Step 7: Encrypt

Encrypt the padded scopedPDU using CBC-DES with the DES key and IV.

Step 8: Set privParameters

Place the salt in the msgPrivacyParameters field.

Step 9: Return Result

Return the encryptedPDU and privParameters.

8.3.2. Processing an Incoming Message

This section describes the procedure followed by an SNMP engine when it processes a message with privacy (encryption).

Step 1: Obtain Privacy Key

Obtain the 16-octet privKey for the user.

Step 2: Extract DES Key

Extract the first 8 octets as the DES key.

Step 3: Obtain Pre-IV

Extract the last 8 octets as the pre-IV.

Step 4: Extract Salt

Extract the salt from msgPrivacyParameters.

Step 5: Calculate IV

XOR the salt with the pre-IV to get the Initialization Vector.

Step 6: Verify Length

Verify that the encrypted data length is a multiple of 8 octets. If not, return an error.

Step 7: Decrypt

Decrypt the encryptedPDU using CBC-DES with the DES key and IV.

Step 8: Remove Padding

Remove any padding from the decrypted data.

Step 9: Return Result

Return the decrypted scopedPDU.

Implementation Notes

Key Length: The privKey MUST be exactly 16 octets for CBC-DES
DES Key Usage: Only the first 8 octets are used as the DES key; the last 8 octets are used for IV generation
Salt Uniqueness: The salt must be unique for each message to ensure IV uniqueness
Padding: Implementations must handle padding correctly, ensuring the encrypted data is always a multiple of 8 octets
Counter Management: The salt counter should be initialized at boot and incremented for each message

Security Considerations

DES Deprecation: DES is considered cryptographically weak by modern standards. The 56-bit effective key length is vulnerable to brute-force attacks
Migration Recommendation: New implementations should consider using stronger encryption algorithms such as AES
IV Uniqueness: It is critical that the IV never repeats for the same key. Implementations must ensure proper salt management
Key Management: The 16-octet privKey must be kept secret and properly managed
CBC Mode: While CBC mode provides confidentiality, it does not provide integrity. The privacy protocol should always be used with authentication