THAM KHẢO

CRYPTO KERNEL API FRAMEWORK

kernel crypto API | IPSEC Layer
|
+-----------+ |
| | (1)
| aead | <----------------------------------- esp_output
| (seqiv) | ---+
+-----------+ |
| (2)
+-----------+ |
| | <--+ (2)
| aead | <----------------------------------- esp_input
| (gcm) | ------------+
+-----------+ |
| (3) | (5)
v v
+-----------+ +-----------+
| | | |
skcipher | | ahash |
| (ctr) | ---+ | (ghash) |
+-----------+ | +-----------+
|
+-----------+ | (4)
| | <--+
| cipher |
| (aes) |
+-----------+

The following call sequence is applicable when the IPSEC layer triggers an encryption
operation with the esp_output function. During configuration, the administrator set up
the use of rfc4106(gcm(aes)) as the cipher for ESP. The following call sequence is now
depicted in the ASCII art above:

1. esp_output() invokes crypto_aead_encrypt() to trigger an encryption operation of the

AEAD cipher with IV generator.

In case of GCM, the SEQIV implementation is registered as GIVCIPHER in

crypto_rfc4106_alloc().

The SEQIV performs its operation to generate an IV where the core function is
seqiv_geniv().
2. Now, SEQIV uses the AEAD API function calls to invoke the associated AEAD
cipher. In our case, during the instantiation of SEQIV, the cipher handle for GCM is
provided to SEQIV. This means that SEQIV invokes AEAD cipher operations with
the GCM cipher handle.
 During instantiation of the GCM handle, the CTR(AES) and GHASH ciphers are
instantiated. The cipher handles for CTR(AES) and GHASH are retained for later
use.

The GCM implementation is responsible to invoke the CTR mode AES and the
GHASH cipher in the right manner to implement the GCM specification.
3. The GCM AEAD cipher type implementation now invokes the SKCIPHER API with
the instantiated CTR(AES) cipher handle.

During instantiation of the CTR(AES) cipher, the CIPHER type implementation of

AES is instantiated. The cipher handle for AES is retained.

That means that the SKCIPHER implementation of CTR(AES) only implements the
CTR block chaining mode. After performing the block chaining operation, the
CIPHER implementation of AES is invoked.
4. The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES cipher
handle to encrypt one block.
5. The GCM AEAD implementation also invokes the GHASH cipher implementation via
the AHASH API.

Tham khảo:
1. RFC 4303: IP encapsulating security payload (esp)
2. RFC 6071: IP Security (IPsec) and Internet Key Exchange (IKE) Document
Roadmap
3. RFC 4106: AES-GCM-ESP
4. RFC 4306 RFC 5282: The IKEv2
5. RFC 2406: IP Encapsulating Security Payload (ESP)
KEYWORD, WORD IN THIS FIELD
Transformation context
Transformation object
NỘI DUNG TÌM HIỂU
I. NGHIÊN CỨU CRYPTO SUBSYSTEM TRONG NHÂN
LINUX
static inline int crypto_aead_decrypt(struct aead_request *req)
{
struct crypto_aead *aead = crypto_aead_reqtfm(req);
 Lấy con trỏ trong trường req gán với con trỏ tfm trong aead
struct crypto_alg *alg = aead->base.__crt_alg;
 LẤY con trỏ pointer TRƯỜNG ALG KIỂU CRYTO_ALG TRONG AEAD RA.
unsigned int cryptlen = req->cryptlen;
 LẤY CHIỀU DÀI DATA MÃ HÓA RA
int ret;
 Biến trả về của hàm
crypto_stats_get(alg);
 \
if (crypto_aead_get_flags(aead) & CRYPTO_TFM_NEED_KEY)
 Lấy cờ crt_flags(32bit) trong tfm của aead (tức là tfm của req)
ret = -ENOKEY;
else if (req->cryptlen < crypto_aead_authsize(aead))
 Nó so sánh crytlen trong request vs aead authsize (được tạo ra chắc là chuẩn j đó vì
aead chỉ có tfm thuộc req còn 2 trường còn lại tự maybe set default )
ret = -EINVAL;
else
ret = crypto_aead_alg(aead)->decrypt(req);
 Copy trường alg trong aead ( kiểu crypto_aead) vào base ( tên của struct mới kiểu
aead_alg để chứa trường alg( crypto_alg ) )rồi trỏ đến decrypt
 Hàm giải mã trỏ vào???  Tìm hiểu sâu hơn nó vô lớp nào??
crypto_stats_aead_decrypt(cryptlen, alg, ret);
 Copy &alg->stats.aead.decrypt_tlen ( data length để xử lý giải mã) vào biến
cryptolen nếu ret ko gặp lỗi, và giảm biến refcnt của alg 1 đơn vị.
return ret;
}
 RETURN: 0 if successful
- EBADMSG if ….
- <0 if error occur
 aead_request: Là 1 struct chứa các biến sau:
* base: Các thuộc tính phổ biến cho các yêu cầu crypto request
* @assoclen: độ dài tính theo byte của associated data cho việc xác thực
* @cryptlen: Độ dài data để encrypt và decrypt
* @iv: Initialisation vector ??? - tìm hiểu kỹ hơn IV
* @src: Source data -
 * @dst: Destination data -
* @__ctx: Start of private context data
 crypto_aead - authenticate + cipher + intergraty
Là 1 struct gồm 3 :
Int Authsize
Int Reqsize
Struct Crypto_tfm base  object để transform

 crypto_tfm???  object để transform

u32 crt_flags;
 cờ crt_flags 32 bits

union {
struct ablkcipher_tfm ablkcipher;
struct blkcipher_tfm blkcipher;
struct cipher_tfm cipher;
struct compress_tfm compress;
} crt_u;  trường lưu object transform theo các kiểu

void (*exit)(struct crypto_tfm *tfm);

 function pointer để exit
struct crypto_alg *__crt_alg;
 Lưu vào alg
void *__crt_ctx[] CRYPTO_MINALIGN_ATTR;
 crypto_alg - định nghĩa giải thuật để cipher algorithm
Là 1 struct gồm các trường sau:
cra_flags: Cờ mô tả sự chuyển đổi này. Xem bao gồm / linux / crypto.h
CRYPTO_ALG_ * cờ cho các cờ đi vào đây. Đó là được sử dụng để tinh chỉnh mô tả của
thuật toán chuyển đổi
cra_blocksize: Kích thước khối tối thiểu của phép chuyển đổi này. Kích thước
tính bằng byte của đơn vị nhỏ nhất có thể được chuyển đổi với thuật toán này. Người
dùng phải tôn trọng giá trị này. Trong trường hợp chuyển đổi HASH, có thể khối nhỏ hơn
cra_blocksize được chuyển đến API mã hóa cho chuyển đổi , trong trường hợp có bất kỳ
loại chuyển đổi nào khác, sẽ xảy ra lỗi trả về bất kỳ nỗ lực nào để chuyển đổi các phần
nhỏ hơn so với cra_blocksize.
cra_ctxsize: Kích thước của bối cảnh hoạt động của chuyển đổi. Giá trị này
thông báo cho API mật mã hạt nhân về kích thước bộ nhớ cần được phân bổ cho bối cảnh
chuyển đổi.
cra_alignmask: Mặt nạ căn chỉnh cho bộ đệm dữ liệu đầu vào và đầu ra. Bộ
đệm dữ liệu chứa dữ liệu đầu vào cho thuật toán phải được căn chỉnh với mặt nạ căn
chỉnh này. Bộ đệm dữ liệu cho dữ liệu đầu ra phải được căn chỉnh theo mặt nạ căn chỉnh
này. Lưu ý rằng API Crypto sẽ thực hiện sắp xếp lại trong phần mềm, nhưng chỉ trong
các điều kiện đặc biệt và có một điểm nhấn về hiệu suất. Việc căn chỉnh lại xảy ra vào
những dịp này đối với các loại
 cra_u khác nhau: mật mã - Đối với cả dữ liệu đầu vào và dữ liệu đầu ra bộ
đệm; ahash - Đối với đầu ra băm đích buf; shash - Đối với đầu ra băm đích. Điều này là
cần thiết trên phần cứng bị lỗi bởi thiết kế và không thể chọn dữ liệu từ các địa chỉ tùy ý.
cra_p Warriority: Ưu tiên thực hiện chuyển đổi này. Trong trường hợp nhiều
phép biến đổi có cùng
cra_name có sẵn cho API Crypto, hạt nhân sẽ sử dụng biến đổi có
cra_p Warriority cao nhất.
cra_name: Tên chung (có thể sử dụng bằng nhiều lần triển khai) của thuật
toán chuyển đổi. Đây là tên của phép biến đổi. Trường này được sử dụng bởi kernel khi
tra cứu nhà cung cấp chuyển đổi cụ thể.
cra_do_name: Tên duy nhất của nhà cung cấp chuyển đổi. Đây là tên của nhà
cung cấp chuyển đổi. Đây có thể là bất kỳ giá trị tùy ý, nhưng trong trường hợp thông
thường, giá trị này chứa tên của chip hoặc nhà cung cấp và tên của thuật toán chuyển đổi
cra_type: Loại chuyển đổi mật mã. Đây là một con trỏ tới struct crypto_type,
thực hiện các cuộc gọi lại phổ biến cho tất cả các loại chuyển đổi
Có nhiều tùy chọn: * crypto_blkcodes_type, * crypto_ablkcodes_type, *
crypto_ahash_type, * crypto_rng_type. Trường này có thể trống. Trong trường hợp đó,
không có cuộc gọi lại chung. Đây là trường hợp cho: mật mã, nén, shash.
cra_u: Cuộc gọi lại thực hiện chuyển đổi. Đây là một liên minh của nhiều cấu
trúc. Tùy thuộc vào loại chuyển đổi được chọn bởi cra_type và cra_flags ở trên, cấu trúc
được liên kết phải là chứa đầy các callback. Trường này có thể trống. Đây là trường hợp
cho ahash, shash.
cra_init: Khởi tạo đối tượng OBJECT biến đổi mật mã. Hàm này được sử
dụng để khởi tạo đối tượng biến đổi mật mã. Hàm này chỉ được gọi một lần tại thời điểm
khởi tạo, phải 5 sau khi bối cảnh chuyển đổi được phân bổ. Trong trường hợp phần cứng
mã hóa có một số yêu cầu đặc biệt cần xử lý bằng phần mềm, chức năng này sẽ kiểm tra
yêu cầu chính xác của phép chuyển đổi và đặt bất kỳ dự phòng phần mềm nào
cra_exit: Khử khử đối tượng biến đổi mật mã. Đây là một đối tác với cra_init,
được sử dụng để xóa các thay đổi khác nhau được đặt trong cra_init.
cra_u.ablkcodes: PHÀN TỬ CỦA UNION chứa mật mã khối không đồng bộ
cra_u.blkcodes: PHẦN TỬ CỦA UNION chứa mật mã khối đồng bộ
cryto_aead  chứa crypto_tfm  chứa cryto_alg
 crypto_aead_reqtfm  __crypto_aead_cast(req->base.tfm)  container_of(tfm, struct
crypto_aead, base); (ptr: the pointer to the member.,Type:the type of the container struct
this is embedded in. member:the name of the member within the struct.
 TẠO 1 BIẾN STRUCT KIỂU CRYPTO_AEAD có chứa tfm TRONG REQUEST
 Crypto_stats_get  crypto_alg_get ( tăng cra_refcnt (reference count trong alg (kiểu
cryto_alg)). Bây h biến cra_refcnt trong alg tăng lên 1
Quá trình giải mã hóa trong esp_output

 Tfm ( object để transform) = crypto_alloc_aead  vào tiếp crypto_alloc_tfm: Xác định vị

trí thuật toán và phân bổ biến đổi. Crypto_alloc_tfm () trước tiên sẽ cố gắng xác định vị
trí thuật toán đã tải. Nếu điều đó không thành công và kernel hỗ trợ các module có thể tải
động, thì nó sẽ cố tải một mô đun cùng tên hoặc bí danh. Nếu thất bại, nó sẽ gửi một truy
vấn tới bất kỳ trình quản lý crypto được tải nào để xây dựng một thuật toán nhanh chóng.
Một số refcount được lấy trên thuật toán alhorithm sau đó được liên kết với biến đổi mới
 crypto_find_alg  crypto_create_tfm . Dùng mode_ put để tải module lên
 Req = aead_request_alloc(…): Phân bổ cấu trúc của request data. Gfp là cờ phân bố bộ
nhớ được xử lý bởi kmalloc của API call. Return sẽ bố trí trình xử lý req trên memỏies
nếu ko trả về null.
 Req = aead_request_set_callback (req, 0, esp_output_done_esn, skb): thiết lập trình
callback khi decrypt/ encrypt xong thì trả về, ngoài ra nó còn nhét data từ skb vào request
 CRYPTO AES-GCM: Structure of Generic AEAD Cipher

Thực thi trong các file cuae gcm (aes): gcm.c; aes-generic.c,ctr.c,ghash-generic.c,seqiv.c
kernel crypto API | IPSEC Layer
|
+-----------+ |
| | (1)
| aead | <----------------------------------- esp_output
| (seqiv) | ---+
+-----------+ |
| (2)
+-----------+ |
| | <--+ (2)
| aead | <-----------------------------------esp_input
| (gcm) | ------------+
+-----------+ |
| (3) | (5)
v v
+-----------+ +-----------+
| | | |
| skcipher | | ahash |
| (ctr) | ---+ | (ghash) |
+-----------+ | +-----------+
|
+-----------+ | (4)
| | <--+
| cipher |
| (aes) |
+-----------+

kernel crypto API | Caller

|
+-----------+ (1) |
| | <------------------ some_function
| ahash |
| (hmac) | ---+
+-----------+ |
| (2)
+-----------+ |
| | <--+
| shash |
| (sha256) |
+-----------+
Một mật mã được tham chiếu bởi người gọi với một chuỗi. Chuỗi đó có ngữ nghĩa sau:

mẫu (mật mã khối đơn)

trong đó, mẫu mã hóa kiểu Cameron và mật mã khối đơn lẻ là mẫu đã nói ở trên và mật
mã khối đơn tương ứng. Nếu có thể, các mẫu bổ sung có thể kèm theo các mẫu khác,
chẳng hạn như

template1 (template2 (mật mã khối đơn)))

API mã hóa hạt nhân có thể cung cấp nhiều triển khai của một mẫu hoặc một mật mã
khối đơn. Ví dụ, AES trên phần cứng mới hơn của Intel có các triển khai sau: AES-NI,
triển khai trình biên dịch chương trình hoặc thẳng C. Bây giờ, khi sử dụng chuỗi Hồi
quy aeses với API mã hóa hạt nhân, triển khai mã hóa nào được sử dụng? Câu trả lời
cho câu hỏi đó là số ưu tiên được gán cho mỗi lần thực hiện mật mã bởi API mã hóa
hạt nhân. Khi người gọi sử dụng chuỗi để chỉ một mật mã trong quá trình khởi tạo
handler mật mã, API mã hóa hạt nhân sẽ tra cứu tất cả các triển khai cung cấp một
triển khai với tên đó và chọn triển khai với mức ưu tiên cao nhất.

 name: the generic name of the cipher that is subject to the priority-based selection –
this name can be used by the cipher allocation API calls (all names listed above are
examples for such generic names)
 driver: the unique name of the cipher – this name can be used by the cipher
allocation API calls
 module: the kernel module providing the cipher implementation (or “kernel” for
statically linked ciphers)
 priority: the priority value of the cipher implementation
 refcnt: the reference count of the respective cipher (i.e. the number of current
consumers of this cipher)
 selftest: specification whether the self test for the cipher passed
 type:
o skcipher for symmetric key ciphers
o cipher for single block ciphers that may be used with an additional template
o shash for synchronous message digest
o ahash for asynchronous message digest
o aead for AEAD cipher type
o compression for compression type transformations
 o rng for random number generator
o givcipher for cipher with associated IV generator (see the geniv entry below for
the specification of the IV generator type used by the cipher implementation)
o kpp for a Key-agreement Protocol Primitive (KPP) cipher such as an ECDH or
DH implementation
 blocksize: blocksize of cipher in bytes
 keysize: key size in bytes
 ivsize: IV size in bytes
 seedsize: required size of seed data for random number generator
 digestsize: output size of the message digest
 geniv: IV generation type:
o eseqiv for encrypted sequence number based IV generation
o seqiv for sequence number based IV generation
o chainiv for chain iv generation
o <builtin> is a marker that the cipher implements IV generation and handling as it
is specific to the given cipher
 II. NGHIÊN CỨU TỔNG HỢP VỀ ESP – IKE – GIẢI
THUẬT KẾT HỢP 2 IN 1 (AES – GCM)
1. Nghiên cứu về ESP: RFC 4303
ESP cung cấp việc:
- Bảo mật mã hóa confidentially.
- Xác thực nguồn gốc data origin authentication,
- Xác định tính toàn vẹn kết nối connectionless integrity,
- Xác định tính lặp lại gói an anti-replay service (a form of partial sequence integrity), and
tính tuyệt mật của data flow ((limited) traffic flow confidentiality).
Các dịch vụ này phụ thuộc vào options mà thời điểm SA được thiết lập và địa điểm thi
hành trong mạng (dựa trên Security policy).
 ESP KHÔNG CHỈ CUNG CẤP MÃ HÓA MÀ CÒN CUNG CẤP HIỆU NĂNG
TỐT TRONG CÁC DỊCH VỤ TRÊN. (THAY VÌ CHỈ DÙNG AH)

Data origin authentication and connectionless integrity :Xác thực nguồn gốc dữ liệu và
tính toàn vẹn không kết nối là các dịch vụ chung , sau đây được gọi chung là 'tính toàn
vẹn'. Nếu xác thực toàn vẹn kết nối thì được tính toán tiếp còn với xác thực nguồn gốc
data thì gián tiếp  ràng buộc khóa key giữa 2 bên khi trao đổi. Đây là 1 dịch vụ
optional, nó được trao đổi,thương lượng ở trình quản lý SA protocols và được config ở
đó (IKE). Dịch vụ này thay thế cho AH vì nó nhanh hơn nhiều xài pipeline

Anti-replay được lựa chọn nếu dịch vụ toàn vẹn data integrity được chọn cho nó. Nó do
người nhận chọn chứ ko do negotiate (thương lượng) trong quá trình SA. ESP không áp
dụng đối với giao thức quản lý SA negotiate tính năng này

The traffic flow confidentialy (TFC) bảo mật lưu lượng tuyệt mật, dùng để che giấu địa
chỉ nguồn và địa chỉ đích của các đối tượng trao đổi. Các đặc trưng mới của TFC ở ÉSP
là tạo và bỏ đi lưu lượng giả, làm đệm tốt hơn cho lưu lượng thật.

1.1.ESP format:
-
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---
-
| Payload Data* (variable) | | ^
~ ~ | |
| |
|Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) |
|ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
-
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- ESP trailer bao gồm: Padding, Pad length, Next Header fields  Thêm vào đó, data ESP
trailer ẩn ( ko đc truyền) thì nằm trong phần xác thực.
- Nếu tính toàn vẹn được chọn, tính toàn vẹn bao gồm SPI, sequence number,payload data
và ESP trailer (cả ngầm ẩn và lộ rõ).
- Nếu dịch vụ bảo mật được chọn, nội dung mã hóa bao gồm ciphertext : Payload data,
ESP trailer.
- IV là trường optional được thêm sau.
- Khi sử dụng bất kỳ thuật toán chế độ kết hợp nào, thuật toán được dự kiến sẽ trả về cả
bản rõ (plaintext) được giải mã và dấu hiệu pass / fail để kiểm tra tính toàn vẹn. Đối với
các thuật toán chế độ kết hợp, ICV thường xuất hiện ở cuối gói ESP (khi toàn vẹn được
chọn) có thể bị bỏ qua. Khi ICV bị bỏ qua và toàn vẹn được chọn, trách nhiệm của thuật
toán chế độ kết hợp là mã hóa trong Payload Data, một phương tiện tương đương ICV
để xác minh tính toàn vẹn của gói.
- Nếu thuật toán chế độ kết hợp chỉ cung cấp tính toàn vẹn cho dữ liệu được mã hóa, thì sẽ
cần sao chép SPI và Sequence Number như một phần của Payload Data.

5
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Cuối cùng, một điều khoản mới được thực hiện để chèn phần đệm Padding cho luồng lưu
lượng bảo mật sau Payload Data và trước đoạn ESP trailer.
- Nếu chế độ đường hầm đang được sử dụng, thì việc triển khai IPsec có thể thêm phần
đệm Bảo mật Lưu lượng Lưu lượng (TFC) sau trường Payload data và trước trường
Padding .
- Nếu chế độ thuật toán kết hợp được sử dụng thì trường ICV sẽ bị bỏ qua. Bởi vì giải
thuật và mode được fixed khi SA được thiếp lập thì format chi tiết của ESP packet sẽ
được fixed cho tất cả traffic sử dụng SA đó.

 SPI: security parameter index (SPI)

SPI là 1 giá trị 32 bit được sử dụng bởi người nhận để xác định SA mà gói tin đến bị ràng
buộc với SA đó. Đây là trường bắt buộc.

Với mỗi SA unicast, SPI được sử dụng bởi chính nó để xác định SA hoặc để sử dụng kết
hợp với các loại IPsec protocol. Bởi vì giá trị SPI được tạo bởi người nhận cho unicast
SA bất kể giá trị đó hiệu quả để xác định SA bởi chính nó hay kết hợp vs các giá trị IPsec
protocol khác là vấn đề nôị bộ. Nếu Ipsec thi hành multicast, nó phải hỗ trợ multicast SA
sử dụng giải thuật để map Ipsec data vs SA. Mỗi entry trong SAD phải xác đích liệu SA
lookup có sử dụng địa chỉ đích hay nuồn Ip address. Đối với truyền multicast, trường SPI
này ko được sử dụng cho SA lookup. Đối với việc gói bảo vệ Ipsec được gửi đến, việc
triển khai phải tiến hành tìm kiếm SAD sao cho tìm thấy mục nhập khớp vs SA dài nhất.
Quá trình tìm kiếm tra cứu SA như sau:
 1. Tìm kiếm SAD cho việc match on tra khớp (SPI, des address, source address). Nếu
SAD entry khớp, xử lý gói ESP inbound packet vs SAD đã tra khớp đó. Ngược lại,
tới bước 2
2. Tìm kiếm SAD cho việc tra khớp ( SPI, des address). Nếu SAD entry khớp, xử lý gói
theo SAD tra khớp đó.
3. Tìm kiếm SAD cho việc tra khớp (SPI)…..
Trong thực tế, với việc thực thi bằng phần mềm, có thể index into hash table bởi SPI. Các
SAD entry của mỗi hash table được giữ sắp xếp để xác định SA dài nhất
 Sequence number: 32 bit field chứa counter được tăng cho mỗi packet gửi  Chống anti-
replay
 Extended sequence numver : 64 bit….
 Payload data
 Padding ( for encryption): 2 nhân tố yêu cầu và động lực sử dụng Padding field.
- Nếu giải thuật mã hóa được sử dụng yêu cầu bản rõ plaintext là bội số của 1 số byte, ví
dụ block size của block cipher, Padding được sử dụng để fill vào plaintext( bao gồm
Payload data,Padding, Pad length, Next header) để đc kích cỡ size phù hợp vs thuật toán
mã hóa
- Padding được yêu cầu, bất kể cả thuật toán mã hóa yêu cầu hay ko => để đảm bảo kích
cỡ của ciphertext chấm dứt ranh giới 4 byte( tức là 4 byte một lần ( nhìn cái sơ đồ packet
là 32 bit) => đảm bảo trương ICV được căn chỉnh 4 byte
- Người gửi có thể thêm vào 0  255 byte của padding.
- Với mục đích để cho số bit mã hóa là bội số của block size, tính toán padding phải được
áp dụng vs payload data, ko bao gồm IV nhưng bao gồm ESP trailer. Nếu là giải thuật
kết hợp ( bao gồm cả mã hóa và xác thuật) yêu cầu SPI và sequence number để xác định
tính toàn vẹn, bản sao chép SPI và sequence number sẽ nằm trong Payload data sau đó
phiên bản sao chép của data này liên kêts vs ICV data ( tương đương) được bao gồm
trong tính toán của pad length.
- Với mục đích đảm bảo ICV được chỉ định ngay tại biên giới 4 byte, việc tính toán
Padding được áp dụng vs payload bao gồm cả IV, pad length, next header. Nếu giải thuật
kết hợp được sử dụng thi bản sao data và dữ liệu tương đương ICV sẽ được nằm trong
payload và được tính toán bởi padding.
 Pad length
- Trường pad length xác định số byte pad trong padding nhưng ko chứa TFC padding
 Next hear
- Next haeder là trường bắt buộc, 8 bit xác định loại data chứa trong Payload data field.
VD: Ipv4/Ipv6, next layer header and data. Giá trị là giá trị IP protocol ( xem trên IANA)
- Nếu Ip proto là 59  no next header  dummy packet  thk nhận discard nó đi.
DUMMY PACKET: CÓ THỂ ĐƯỢC THÊM Ở KHOẢNG NGUẪ NHIÊN ĐỂ CHE ĐI
LƯU LƯỢNG THỰC SỰ
 TFC padding:
- TFC được thêm vào trước Padding, sau Paylload data để đệm thêm byte ( ko có chuẩn j
cho việc tính toán ra đc value ở field này). Trương này chỉ thêm vào khi Payload data
 chúa độ dài cụ thể của IP datagram => Nhờ length trong này mà người nhận có thể bỏ
được TFC padding bởi giá trị thật thì thk Payload biết rồi. Nếu TFC padding được thêm
vào thì cái field chứa độ dài cụ thể của Ip datagram này ko đc hiệu chỉnh để bao gồm
TFC padding.
 ICV: độ dài biến thiên  được tính dựa trên ESP header (SPI, seq num), payload, esp
trailer(padding, pad length, next header)  dựa trên gaiir thuật bảo toàn vẹn được xác
định trong SA.

1.2. Quá trình ESP

Có 2 mode: trans vs tunnel
Vs transport mode:

BEFORE APPLYING ESP

----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------

AFTER APPLYING ESP

-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
Vs tunnel mode:

BEFORE APPLYING ESP

----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------

AFTER APPLYING ESP

-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|

1.3. Quá trình xử lý Packet ra ngoài

 Lookup SA
 Mã hóa packet và tính ICV vs giải thuật combine ( 2trong 1)
Người gửi phải theo process như sau:
- Đóng gói vào ESP payload data field
 + Với transport mode : chỉ đóng gói thông tin gốc của next layer ( vd: Ip, TCP)
+ Với Tunnel mode: đóng gói toàn bộ IP datagram gốc.
- Thêm padding cần thiết, bao gồm TFC padding và Padding
- Việc Mã hóa và toàn vẹn giúp bảo vệ kết quả sử dụng key và giải thuật kết hợp (vd AES-
GCM) đc xác định bởi SA và sử dụng bất kỳ data đồng bộ mã hóa yêu cầu
+ Nếu nó data đồng bộ mã hóa lộ rõ như IV ( ko mã hóa), nó chính là input của giải thuật
kết hợp (VD: AES-GCM) và nó đặt ở payload field (thực ra là nagy trước).
+ Nếu là data đồng bộ mã hóa ko lộ rõ, nó đc xây dựng và là input của giải thuật mã hóa.
+ seq number và SPI là input của giải thuật => nó phải bao gồm trong kiểm tra tính toàn
vẹn (xác thực)
+ ICV (lộ rõ) là một phần packet format khi giải thuật kết hợp (AES-GCM được kết hợp)

 Tạo Seq number:

Bộ đếm của người gửi được khởi tạo là 0 khi SA được thiết lập. Người gửi tăng bộ đếm
số thứ tự (hoặc ESN) cho SA này và chèn 32 bit thứ tự thấp của giá trị vào trường Seq
number. Do đó, gói đầu tiên được gửi bằng SA đã cho sẽ chứa số thứ tự là 1.
Nếu tính năng chống phát lại được bật (mặc định), người gửi sẽ kiểm tra để đảm bảo rằng
bộ đếm chưa có vòng nào nào trươcs đó trước khi chèn giá trị mới vào trường Seq
number. Nói cách khác, người gửi KHÔNG ĐƯỢC gửi gói trên SA nếu làm như vậy sẽ
khiến Seq number bị lặp vòng tròn(????).
Nếu key sử dụng cho tính ICV đc phân phối thủ công ( ko tự đông) => Ko nên dùng dịch
vụ anti-replay.
Nếu anti-replay disable thì sender ko cần kiểm soát hoặc reset counter. Tuy nhiên, sender
sẽ tăng counter này khi nó đặt max value, counter về 0.
Nếu ESN được chọn, chỉ 32 bit thấp trong seq num được truyền trong trường seq number
field, mặc dù cả sender và recv đều duy trì 64 bit esn counter. 32 bit cao sẽ nằm trong
việc check toàn vẹn , nó thường nằm gắn phái dưới next header.
 Fragmentation
1.4.Quas trình xử lý gói đi vào
 Lắp ráp lại
Đối vs fragment….
 SA look up: Dựa trên SPI  xác định các mục entry trong SAD để tra cứu SA thích hợp
trong SAD. Các mục SA entry trong SAD còn xác định có cần kiểm tra Seq number hay
ko? Xác định ICV field (lộ rõ) có hay ko ( nếu có thì cho biết size), xác định giải thuật
+key cho giải mã và tính toàn ICV. Mấy gói trao đổi SA, quản lý Sa như IKE packet thì
được xử lý ko dựa trên SPI.

 Xác thực tính hợp lệ của Seq number:

- Nếu người nhận đã enable dịch vụ anti-replay cho SA này, Counter của packet của người
nhận cho SA này phải được khởi tạo từ 0 khi SA bắt đầu được thiết lập. Với mỗi gói
nhận được, người nhận phải xác nhận rằng packet chứa Seq number ko trùng vs Seq
number của packet khác trong SA lifetime… (Tìm hiểu tiếp )
 Xác thực ICV value vs giải thuật kết hợp:
Người nhận làm theo quá trình sau:
- Giải mã và kiểm tra tính toàn vẹn ESP payload data, padding, pad length và next header
sử dụng key và giải thuật và dữ liệu đồng bộ mã hóa (IV) (được xác định bởi SA).
Trường SPI trong ESP header và Giá trị counter của người nhận là input của giải thuật vì
nó là bắt buộc yêu cầu cho kiểm tra tính toàn vẹn
+ Dữ liệu đồng bộ mã hóa (lộ rõ)( IV) được xác định từ Payload field và là input của giải
thuật mã hóa.
+ Dữ liệu đồng bộ mã hóa ( ẩn) –IV . Phiên bản cục bộ của IV được xây dựng và là input
của 1 số giair thuật
- Nếu kiểm tra tính toàn vẹn đc thực hiện bởi gaiir thuật kết hợp fail => bỏ Ip datagram
- Xử lý Padding trong giải thuật mã hóa
- Receiver kiểm tra Next header, nếu giá trị đó là 59, gói dummy bị bỏ mà ko xử lý tiếp.
- Giải ra Ip data gốc (tunnel mode) hay frame transport (transport mode) từ ESP Payload
Data field. Nó sẽ ngầm bỏ đi padding.
2. Nghiên cứu về IKEv2: RFC 4306 – The Internet Key Exchange
IKE là thành phần của IPsec để xác thực và duy trì SA. IKE sử dụng xác thực lẫn nhau
(mutual anthentication) giữ 2 bên để thiếp lập IKE SA ( bao gồm các thông tin bí mật sử
dụng cho thiết lập SA cho ESP và các giải thuật crypto mà có sử dụng SA để bảo vệ lưu
lượng.
2.1.Giới thiệu cách gọi, khái quát IKE
Ở đây, ta gọi IKE SA Là IKE_SA. SAS cho ESP được thiết lập từ IKE_SA được gọi là
CHILD_Sas
Tất cả giao tiếp IKE đều bao gồm : request và response => Trao đổi.
+ Tin nhắn đầu tiên thiết lập: trao đổi IKE_SA IKE_SA_INIT và IKE_AUT
+ IKE trao đổi tiếp theo là : CREATE_CHILD_SA và INFORMATIONAL
Thường thì chỉ có 1 IKE_SA_INIT vs IKE_auth ( TỔNG CỘNG 4 GÓI) để thiết lập
IKE_SA và CHILD_SA đầu tiên. Trong 1 số trường hợp ngoại lệ, có nhiều hơn. Trong
tất cả case, tất cả trao đổi IKE_SA_INIT phải kết thúc trước khi trao đổi cái khác, sau đó
tất cả IKE_AUT phải được hoàn thành, còn CREATE_CHILD)SA và
INFORMATIONAL trao đổi có thể xảy ra theo bất kỳ thứ tự nào. Trong 1 số trường hợp,
chỉ duy nhất 1 CHILD_SA được dùng cần thiết tại các IPsec endpoints  ko cần thêm
trao đổi, những CHILD_SA sau dùng để xác thực cặp endpoints.
Nếu quá timeout mà ko nhận đc resonse (ACK) => truyền lại request.
Cặp req/res đầu tiên trong phiên trao đổi IKE (IKE_SA_INIT) trao đổi thông số bả mật
cho IKE_SA: Gửi nonces (IV), gửi giá trị Difile Hellman ( chắc là ko đối xứng…)
Cặp req/res tiếp theo thứ hai (IKE_AUTH) truyền các danh tính chứng minh các thông
tin tương ứng vs 2 danh tính và thiết lập SA cho ESP CHILD_SA đầu tiên.
Các loại trao đổi tiếp theo là CREATE_CHILD_SA (tạo ra CHILD_SA) và
ÌNORMATIONAL (xóa SA, báo cáo lỗi điều kiện hoặc thực hiện DỌN DẸP khác). Mỗi
yêu cầu yêu cầu một phản hồi. Một yêu cầu INFORMATIONAL không có PAYLOAD
(trừ PAYLOAD được mã hóa trống theo yêu cầu của cú pháp) thường được sử dụng như
một kiểm tra về mức độ sống. Những trao đổi tiếp theo không thể được sử dụng cho đến
khi các trao đổi ban đầu đã hoàn thành.
2.2.Các trường hợp sử dụng
- Security Gateway to Security Gateway Tunnel ( 2mangj Subnet, 2 router,..)
- Endpoint-to-Endpoint Transport ( 2 điểm đầu cuối).
- Endpoint to Security Gateway Tunnel
2.3. Trao đổi khởi tạo
Bắt đầu vs IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1).
Gồm 4 messages, chứa cặp req vs res.
Cặp trao đổi IKE_SA_INIT sẽ trao đổi: giải thuật mã hóa, nonces (IV), giá trị Diffie-
Hellman
Cặp trao đổi IKE_AUTH xác thực thông tin messages trước, trao đổi danh tính và
certificate  Thiết lập CHILD-SA đầu tiên. Một phần những messages này sẽ bị mã hóa
và bảo toàn vẹn bằng keys thiết lập được từ IKE_SA_INIT.
Payloads trong những message này sẽ chứa các thông tin sau:
Ký hiệu Payload
AUTH Authentication
CERT Certificate
CERTREQ Certificate Request
CP Configuration
D Delete
E Encrypted
EAP Extensible Authentication
HDR IKE Header
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange
Ni, Nr Nonce
N Notify
SA Security Association
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
V Vendor ID
IKE_SA_INIT
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
Bên khởi tạo: HDR chứa SPIs, version num, flags của sự sắp xếp. Sai1 chứa giải thuật mã
hóa mà thằng khởi taọ hỗ trợ cho IKE_SA. KE là cái key: Là giá trị của đứa khởi tạo cho
Diffie-Hellman cho IKE_SA. Ni là IV, (nonces) (tạo bởi Pseudo Random Function) của
thằng khởi tạo.
Bên hồi đáp sẽ chọn giải thuật mã hóa crypto từ thằng khởi tạo đề nghị và truyền đạt sự
lựa chọn của nó trong SAr1, hoàn thành trao đổi Difie-Hellman trong Key payload, gửi
giá trị nonces (IV) của nó trong Nr payload. Vào thời điểm trao đổi, mỗi bên sẽ tạo 1 cái
SKEYSEED, từ đó mã tất cả các key được lấy cho quá trình IKE_SA. Tất cả ngoại trừ
headers của tất cả messages sẽ được mã háo và xác thực bởi keys lấy từ SKEYSEED.
Trong đó SK_e (cho encrypt) và SK_a (cho authenc) được tính riêng biệt tại mỗi bên, lấy
từ DH value để bảo vệ IKE_SA. Một khóa khác là SK_D được lấy và sử dụng để là vật
liệu tạo khóa cho CHILD_SAS

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]

AUTH, SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,]
AUTH,SAr2, TSi, TSr}
Bên khởi tạo sẽ assert ( khẳng định) danh tính của mình vs IDi payload ( được mã hóa),
chứng minh hiểu biết của nó về secret tương ứng vs Idi và bảo toàn sự toàn vẹn nội dung
của message đầu tiên sử dụng AUTH payload. Nó còn gửi certificate trong CERT
payload. Nếu bất kỳ CERT payload được bao gồm, CERT đầu tiên phải chứa public key
sử dụng xác thực cho AUTH field. Payload Idr (optional)  Chỉ định danh tính của bên
kia mà nó muốn nói chuyện . Vì 1 devices có nhiều danh tính trên 1 Ip addresses. Bên
khởi tạo phải bắt đầu trao đỏi CHILA_SA vs việc sử dụng SAi payload.
Bên hồi đáp sẽ khanwngr định danh tính của mình bằng trường IDr payload, gửi nhiều
certificates ( có chứa public key để xác thực AUTH), xác thực và bảo vệ toàn vẹn bằng
AUTh payload => Kết thúc thảo luận về CHILD_SA bằng thêm một số trường fields sau.
Xác thực trong IKE_SA: Tham khảo mục 2.8
2.4.Trao đổi CREATE_CHILD_SA
Nó từng là phase 2 trong IKEv1.
CHILD_SA được tạo ra bằng cách gửi CREATE_CHILD_SA request.( Có thể có chứa
thêm Kei sử dụng Diffie hellman để tăng độ mạnh mã hóa CHILD_SA)

Initiator Responder
----------- -----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->

<-- HDR, SK {SA, Nr, [KEr],

[TSi, TSr]}
2.5.Trao đổi INFORMATIONAL
Initiator Responder
 ----------- -----------
HDR, SK {[N,] [D,] [CP,] ...} -->
<-- HDR, SK {[N,] [D,] [CP], ...}
 Mục đích: Thông báo lỗi hoặc sự kiện ( Delete, Config payload). Người gửi phải chứ
payload, người nhận có thể payload =0

2.6.Cách tạo khóa key material
Pseudo radom function được sử dụng cho tạo khóa key cho tất cả IKE_SA và
CHILD_SA
prf+ (K,S) = T1 | T2 | T3 | T4 | ...

where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
VD:nếu các khóa bắt buộc là khóa AES 256 bit và khóa HMAC 160 bit và chức năng prf
tạo ra 160 bit, thì khóa AES sẽ đến từ T1 và đầu T2, trong khi HMAC sẽ đến từ phần còn
lại của T2 và đầu T3)
2.7.Cách tạo Key material cho IKE_SA
Khóa chung được tính như sau: Một số lượng được gọi là SKEYSEED được tính từ
nonces (được trao đổi trong suốt IKE_SA_INIT trao đổi) và giá trị Diffie-hellman chung
được thiết lập trong quá trình trao đổi này. SKEYSEED được sử dụng để tính 7 key:
SK_d ( sử dụng để tạo key material cho CHILD_SAs => tạo key cho CHILD_SA( thiết
lập vs IKE_SA này); SK_ai và SK_ar được sử dụng cho giải thuật bảo vệ toàn vẹn;
SK_ei và SK_er cho mã hóa; SK_pi và SK_pr được sử dụng khi tạo AUTH payload.)
SKEYSEED và những thứ đc gọi ( làm từ nó):
SKEYSEED = 9 crgbv dfcxYH10:30 PM | Nr, g^ir)

{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+

(SKEYSEED, Ni | Nr | SPIi | SPIr )
g ^ ir là giá trị bí mật được chia sẻ từ trao đổi tạm thời Diffie-Hellman . g ^ ir được biểu
diễn dưới dạng một chuỗi các octet theo thứ tự big endian được đệm bằng các số không
nếu cần thiết để làm cho nó có độ dài của mô đun. Ni và Nr là các nonces. Nếu prf trao
đổi thương lượng lấy khóa có độ dài cố định và độ dài của Ni và Nr không cộng với độ
dài đó, một nửa bit phải đến từ Ni và một nửa từ Nr, lấy các bit đầu tiên của mỗi bit.
2.8.Xác thực cho IKE_SA
 Đối vs message đầu tiên và thứ 2
Khi sử dụng ( ko sử dụng xác thực mở rộng), 2 bên phải được xác thực bằng cách có
sign riêng ( hay Mac sử dụng shared secret là key) – là block của data. Đối vs người hồi
đáp, octects làm sign (ký hiệu) bắt đầu là octect đầu tiên của SPI đầu tiên trong header
của tin nhắn thứ 2. Thêm vào điều này ( cho mục đích tính được signature - là 1 ký hiệu
 của mỗi bên) là nonce Ni của người khởi tạo ( giá trị) và giá trị prf(SK_pr,IDr’) là ID
của bên hồi đáp (ko nằm trong header cố định). Chú ý rằng cả giá trị Ni và prf(…) ko
được truyền đi. Cũng giống vậy, bên khởi tạo cũng đặt ký hiệu ở tin nhắn đầu tiên (cặp
đầu tiên của phase 1), bắt đầu vs byte đầu của SPI đầu tiên và kết thúc bởi octect cuối
của payload. Thêm vào đó ( cho mục đích tính signature). Là Nr của bên response và giá
trị (SK_pi,Idi’). Trong tính toán trên, IDi 'và IDr' là toàn bộ tải trọng ID
không bao gồm fixed header. Điều quan trọng đối với bảo mật của trao đổi là mỗi bên
ký vào nonce của bên kia  Đối với bên phản hồi: Bên này sẽ sử dụng Ni ( nonce của
bên init từ first message) và hàm prf ( sử dụng IDr’) để tính signature của bên phản hồi
ứng vs Nonce của bên init). Đối vs bên khởi tạo: Tính signature của nó dựa trên nonce
của bên phản hồi.
 Đối vs cặp message xác thực ( mess 3 và 4 ):
Nó sử dụng certificate, chuỗi certificate để cung cấp dữ liệu bằng chứng chứng minh key
sử dụng để tính digital signature thuộc về ID đó. Có thể sử dụng MAC(shared key) ( ko
an toàn) hay public signature key vs certificate. Signature hay Mac tính từ giải thuật phụ
thuộc vào key của bên nào, ko yêu cầu cùng 1 giải thuật. Thường thì pre-share key (
mac) được sử dụng để xác thực vì nó same key 2 phía.
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)

2.9.Trao đổi thương lượng thuật toán mã hóa

Payload SA chỉ định đề xuất 1 tập các giao thức IPsec (IKE, ESP) cho SA và giải thuật
liên kết vs protocol đó.
Cấu trúc payload này được thiết kế để encode đề xuất giao thức và thuật toán mã hóa cho
nó ( 1 hoặc nhiều cái proto, mỗi cái proto lại có 1 hoặc nhiều algorithm). Bên phản hồi
phải chọn 1 cái trong cái đề xuất SA này.
2.10. REKEYING, tạo key lại
Có thể tạo key lại trong IKE_SA ko cần thiết lập lại toàn bộ quá trình đó. Mỗi SA sẽ chủ
động rekey vì nó có lifetime nên trước khi hết hạn nó sẽ đổi key của SA. Việc rekey
CHILD_SA nằm trong IKE_SA có sẵn thì ta phải tạo lại cái mới – một SA tương đương,
sau khi tọa xong thì xóa cái cũ. Việc rekey IKE_SA thì ta tạo 1 cái mới tương đương cái
cũ sử dụng là CHILD_SA cũ tồn tại trong cái cũ.( Xem mục 2.12)
2.11. Tạo Key material cho CHILD_SAs
- Là 1 chuỗi bit j đó mà từ đó tạo cắt 1 phần nào đó để làm key mã hóa, key xác thực.
- KEYMAT = prf+(SK_d, Ni | Nr) Với Ni/Nr lấy từ trao đổi
IKE_SA_INIT

- KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) vs g^ir là giá trị

Difie Hellman (optional field in first mess pair in phase 2 –
CREATE_CHILD_SA)
2.12. Rekeying IKE_SAs sử dụng trao đổi CREATE_CHILD_SA:
Trao đổi CREATE_CHILD_SA có thể được sử dụng để rekey một IKE_SA đã tồn tại.
SKEYSEED cho IKE_SA mới được tính từ SK_d cũ của IKE_SA như sau:
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
Với g^ir ( mới) là giá trị Diffie-Hellman lấy từ CREATE_CHILD_SA (trao đổi). Từ
SKEYSEED này tính lại SK_d, SK_ai, SK_ar, SK_ei.
2.13. Nghiên cứu packet của IKE
TO BE CONTINUED …
3. NGHIÊN CỨU AES-GCM: RFC 4106
3.1. Khái quát:
 CTR (Counter mode) tốc độ cao hơn CBC ( Cipher Block chaining) vì nó pipeline, tuy
nhiên ko có xác thực nguồn gốc => Nhược diểm
 GCM bao gồm CTR và có giải thuật xác thực.

3.2. AES-GCM đầu vào- ra:

 4 inputs: 1 secret key ( từ Child_sa), 1 IV, 1 palintext, input cho AAD ( authenticated
data).
 2 outputs: 1 ciphertext ( tương ứng vs 1 plaintext(ánh xạ)),1 authentication tag (ICV).

3.3. Nonce format

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trong đó:
Salt: 4 octect: được chỉ định bắt đầu 1 SA, kéo dài là = const hết lifetime của SA.
IV: 8 octects

3.4. Cấu trúc của AAD

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: AAD Format with 32-bit Sequence Number

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: AAD Format with 64-bit Extended Sequence Number

3.5.ICV
Chỉ bao goomg authentication tag. Gồm 2 loại : 16 octects vs 8/12 octects
3.6.Keying material và Salt Value
KEYMAT ( tham khảo trong Chilad _sa của Ike):
 AES-GCM-ESP with a 128 bit key
The KEYMAT requested for each AES-GCM key is 20 octets. The first
16 octets are the 128-bit AES key, and the remaining four octets
are used as the salt value in the nonce.

 AES-GCM-ESP with a 192 bit key

The KEYMAT requested for each AES-GCM key is 28 octets. The first
24 octets are the 192-bit AES key, and the remaining four octets
are used as the salt value in the nonce.

 AES-GCM-ESP with a 256 bit key

The KEYMAT requested for each AES GCM key is 36 octets. The first
32 octets are the 256-bit AES key, and the remaining four octets
are used as the salt value in the nonce.