[pcap-ng-format] Proposal for Encrypted Block (3 of 4)

[Michael Haney]

I'd like to propose the following Encrypted Block type:

<artwork>
 0                   1                   2                   3
 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
+---------------------------------------------------------------+
|                    Block Type = 0xAAAAAAAA                    |
+---------------------------------------------------------------+
|                      Block Total Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Encr. Type  |   DUKPT opts  |  16-bit=first 2 bytes of MAC  |
+---------------+---------------+-------------------------------|
|             Four more bytes of sniffer's MAC address          |
+---------------------------------------------------------------|
|              Org-defined Key Set Identifier (KSI)             |
+---------------------------------------------------------------|
|                                                               |
|             64 bits = encryption transaction counter          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Encrypted Data                          |
|              /* variable length, byte-aligned */              |
|                                                               |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  |         Embedded Block Type = 0x00000006                |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  |                    EPB Total Length                     |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  |                                                         |  |
|  |                 Original Enhanced Packet Block          |  |
|  |                   with HMAC hash option                 |  |
|  |                                                         |  |
|  |                                                         |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  |         hash of plaintext packet contained for later    |  |
|  |                  integrity verification                 |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  |                    EPB Total Length                     |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |    padded by block cipher     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Block Total Length                       |
+---------------------------------------------------------------+


The design presented here extends the current PcapNG format specification by
defining the previously proposed Encrypted Block.  In its basic form, the
block
consists of a plaintext field and an encrypted filed, surrounded by the
PcapNG
header and footer.  The plaintext field should provide enough information to
correctly identify the encryption algorithm and secret key necessary for
recovering the contents of the encrypted field.  Those contents should
contain another PcapNG block, inclucing its own header and footer.

In the proposed design, the cryptographic key management system used to
produce
secret (symmetric) keys for encrypting EPBs is DUKPT: "Derived Unique Key
Per
Transaction". This method is specified in ANSI standard X9.24-1 and is
intended
to produce a unique key per electronic credit card transaction, and is
based on
3DES. It has been modified in several ways for application to network
recording,
specifically to be based on AES, Twofish, or potentially other symmetric-key
block ciphers, uses longer keys, and has a much larger
encryption/transaction
counter.

In this application, the Key Serial Number (KSN) corresponds to the Flow
Identification number.  It is 20 bytes long. It includes 1 byte to
designate the
encryption type (0x01 = "DUKPT"), one byte to specify DUKPT options (0xA6 =
"AES"), 10 bytes for a Key Set Identifier (KSI) which may consist of a
6-byte
MAC address of the sniffing interface and 4-byte organization or session
ID, and
8 bytes (64 bits) to represent the unique encryption counter. Strictly
speaking,
there are 63 bits in the encryption counter, and the leading bit must be 0.

Block Type: The system assumes a value of 0xAAAAAAAA for the proposed
Encrypted
Block type. This is represented in binary as
0b10101010101010101010101010101010,
a particularly non-random looking sequence. The block total length is
calculated
as it is for all blocks.

Encryption Type and DUKPT Options: The first fields of the Encrypted Block
are
the two bytes for “encryption type” and “DUKPT Options.” In keeping with
the
PcapNG block format of designating a “type” to allow for multiple
implementations of a particular class of file block, the first byte is used
to
identify that a DUKPT-based encryption scheme is being used, and the type
chosen
for this design is 0x01. The second field allows for various options to be
chosen for the implementation of DUKPT. The ANSI X9.24-1 standard
describing
DUKPT also includes a number of other encryption schemes defined, and each
is
assigned a designator that is to be part of a security management
identifier
(SMID). The assigned value for DUKPT-3DES is “0xA5.” In the design
presented
here, this byte should be set to “0xA6” for DUKPT-AES or “0xA7” for
DUKPT-Twofish.

Flow ID as the Key Serial Number: In order to uniquely identify a flow in a
network recording, one needs to assign each flow an ID number. In order to
work
with DUKPT, an encryption counter must be incremented to create a unique
Key
Serial Number (KSN). This KSN is encoded with enough information for a
receiver
to identify a Base Derivation Key and be able to use the counter in the KSN
to
re-derive the appropriate key. In order to associate a key with a
particular
flow, one needs to map the KSN to the Flow ID. In the design presented
here, the
Flow ID is the KSN, with one small addition.

The KSN consists of two parts: the encryption counter which makes each
serial
number unique, and the key set identifier which groups all keys associated
with
a starting base derivation key. In the original DUKPT specification, the
KSI is
59 bits and the counter is 21 making a KSN 80 bits or 10 bytes long. In the
new
design, the KSN is 18 bytes: 10 bytes for the KSI and 8 bytes (minus one
reserved bit) for the counter. For the Flow ID, which must be compatible
with
PcapNG’s requirement to align with 32-bit boundaries, it includes two
additional
bytes as described earlier: one for “encryption type” and one for future
DUKPT
options. The total Flow ID is then 20 bytes in length. This allows for
roughly
4 quintillion possible unique flow IDs per sensor.

The second part of the Encrypted Block is the encrypted payload. The first
part
provides enough public information to retrieve the appropriate key to
decrypt
the contents. The second (encrypted) part must be treated as one field. When
decrypted, it must yield an in-tact well-formed PcapNG block. In this
design,
this is a complete Enhanced Packet Block that includes a hash option to
verify
integrity of the block. More specifically, the hash should use a keyed HMAC
option. DUKPT provides the means to derive an additional key from the
encryption
key used for hashing. It can be rederived at the time of validating the
hash.

Details of how DUKPT works are beyond the scope of this file format
specification. Refer to ANSI X9.24-1, Appendix A, for the DUKPT algorithm
based
on DES and 3DES-ede, and generally substitute AES or Twofish with
double-length
registers and keys, and a triple-length encryption counter and shift
register.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150827/1f6372ef/attachment.html>