<div dir="ltr"><span style="font-family:monospace,monospace">I'd like to propose the following Encrypted Block type:<br><br><artwork><br> 0                   1                   2                   3 <br> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br>+---------------------------------------------------------------+<br>|                    Block Type = 0xAAAAAAAA                    |<br>+---------------------------------------------------------------+<br>|                      Block Total Length                       |<br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>|   Encr. Type  |   DUKPT opts  |  16-bit=first 2 bytes of MAC  | <br>+---------------+---------------+-------------------------------| <br>|             Four more bytes of sniffer's MAC address          | <br>+---------------------------------------------------------------| <br>|              Org-defined Key Set Identifier (KSI)             | <br>+---------------------------------------------------------------|  <br>|                                                               | <br>|             64 bits = encryption transaction counter          | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>|                       Encrypted Data                          |<br>|              /* variable length, byte-aligned */              |<br>|                                                               |<br>|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |<br>|  |         Embedded Block Type = 0x00000006                |  |<br>|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |<br>|  |                    EPB Total Length                     |  |<br>|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |<br>|  |                                                         |  |<br>|  |                 Original Enhanced Packet Block          |  |<br>|  |                   with HMAC hash option                 |  |<br>|  |                                                         |  |<br>|  |                                                         |  |<br>|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |<br>|  |         hash of plaintext packet contained for later    |  |<br>|  |                  integrity verification                 |  |<br>|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |<br>|  |                    EPB Total Length                     |  |<br>|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |<br>|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>|                               |    padded by block cipher     |<br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>|                      Block Total Length                       |<br>+---------------------------------------------------------------+<br><br><br>The design presented here extends the current PcapNG format specification by<br>defining the previously proposed Encrypted Block.  In its basic form, the block<br>consists of a plaintext field and an encrypted filed, surrounded by the PcapNG<br>header and footer.  The plaintext field should provide enough information to<br>correctly identify the encryption algorithm and secret key necessary for <br>recovering the contents of the encrypted field.  Those contents should<br>contain another PcapNG block, inclucing its own header and footer.<br><br>In the proposed design, the cryptographic key management system used to produce<br>secret (symmetric) keys for encrypting EPBs is DUKPT: "Derived Unique Key Per<br>Transaction". This method is specified in ANSI standard X9.24-1 and is intended<br>to produce a unique key per electronic credit card transaction, and is based on<br>3DES. It has been modified in several ways for application to network recording,<br>specifically to be based on AES, Twofish, or potentially other symmetric-key<br>block ciphers, uses longer keys, and has a much larger encryption/transaction<br>counter.<br><br>In this application, the Key Serial Number (KSN) corresponds to the Flow<br>Identification number.  It is 20 bytes long. It includes 1 byte to designate the<br>encryption type (0x01 = "DUKPT"), one byte to specify DUKPT options (0xA6 = <br>"AES"), 10 bytes for a Key Set Identifier (KSI) which may consist of a 6-byte<br>MAC address of the sniffing interface and 4-byte organization or session ID, and<br>8 bytes (64 bits) to represent the unique encryption counter. Strictly speaking,<br>there are 63 bits in the encryption counter, and the leading bit must be 0.<br><br>Block Type: The system assumes a value of 0xAAAAAAAA for the proposed Encrypted <br>Block type. This is represented in binary as 0b10101010101010101010101010101010,<br>a particularly non-random looking sequence. The block total length is calculated<br>as it is for all blocks. <br><br>Encryption Type and DUKPT Options: The first fields of the Encrypted Block are <br>the two bytes for “encryption type” and “DUKPT Options.” In keeping with the <br>PcapNG block format of designating a “type” to allow for multiple <br>implementations of a particular class of file block, the first byte is used to <br>identify that a DUKPT-based encryption scheme is being used, and the type chosen<br>for this design is 0x01. The second field allows for various options to be <br>chosen for the implementation of DUKPT. The ANSI X9.24-1 standard describing <br>DUKPT also includes a number of other encryption schemes defined, and each is <br>assigned a designator that is to be part of a security management identifier <br>(SMID). The assigned value for DUKPT-3DES is “0xA5.” In the design presented <br>here, this byte should be set to “0xA6” for DUKPT-AES or “0xA7” for <br>DUKPT-Twofish.<br><br>Flow ID as the Key Serial Number: In order to uniquely identify a flow in a<br>network recording, one needs to assign each flow an ID number. In order to work<br>with DUKPT, an encryption counter must be incremented to create a unique Key <br>Serial Number (KSN). This KSN is encoded with enough information for a receiver <br>to identify a Base Derivation Key and be able to use the counter in the KSN to <br>re-derive the appropriate key. In order to associate a key with a particular <br>flow, one needs to map the KSN to the Flow ID. In the design presented here, the <br>Flow ID is the KSN, with one small addition.<br><br>The KSN consists of two parts: the encryption counter which makes each serial<br>number unique, and the key set identifier which groups all keys associated with <br>a starting base derivation key. In the original DUKPT specification, the KSI is <br>59 bits and the counter is 21 making a KSN 80 bits or 10 bytes long. In the new <br>design, the KSN is 18 bytes: 10 bytes for the KSI and 8 bytes (minus one <br>reserved bit) for the counter. For the Flow ID, which must be compatible with <br>PcapNG’s requirement to align with 32-bit boundaries, it includes two additional<br>bytes as described earlier: one for “encryption type” and one for future DUKPT <br>options. The total Flow ID is then 20 bytes in length. This allows for roughly <br>4 quintillion possible unique flow IDs per sensor.<br><br>The second part of the Encrypted Block is the encrypted payload. The first part<br>provides enough public information to retrieve the appropriate key to decrypt <br>the contents. The second (encrypted) part must be treated as one field. When<br>decrypted, it must yield an in-tact well-formed PcapNG block. In this design,<br>this is a complete Enhanced Packet Block that includes a hash option to verify<br>integrity of the block. More specifically, the hash should use a keyed HMAC<br>option. DUKPT provides the means to derive an additional key from the encryption<br>key used for hashing. It can be rederived at the time of validating the hash.<br><br>Details of how DUKPT works are beyond the scope of this file format <br>specification. Refer to ANSI X9.24-1, Appendix A, for the DUKPT algorithm based<br>on DES and 3DES-ede, and generally substitute AES or Twofish with double-length <br>registers and keys, and a triple-length encryption counter and shift register.<br><br></span></div>