Header konteks di ASP.NET Core

Artikel
11/30/2023

Latar belakang dan teori

Dalam sistem perlindungan data, "kunci" berarti objek yang dapat menyediakan layanan enkripsi terautentikasi. Setiap kunci diidentifikasi oleh id unik (GUID), dan membawa informasi algoritma dan materi entropis. Ini dimaksudkan bahwa setiap kunci membawa entropi unik, tetapi sistem tidak dapat memberlakukan itu, dan kita juga perlu memperhitungkan pengembang yang mungkin mengubah cincin kunci secara manual dengan memodifikasi informasi algoritma dari kunci yang ada di cincin kunci. Untuk mencapai persyaratan keamanan kami mengingat kasus-kasus ini, sistem perlindungan data memiliki konsep kelincahan kriptografi, yang memungkinkan penggunaan nilai entropik tunggal dengan aman di beberapa algoritma kriptografi.

Sebagian besar sistem yang mendukung kelincahan kriptografi melakukannya dengan menyertakan beberapa informasi identifikasi tentang algoritma di dalam payload. OID algoritma umumnya merupakan kandidat yang baik untuk ini. Namun, salah satu masalah yang kami alami adalah ada beberapa cara untuk menentukan algoritma yang sama: kelas "AES" (CNG) dan Aes terkelola, AesManaged, AesCryptoServiceProvider, AesCng, dan RijndaelManaged (parameter tertentu tertentu) semuanya sebenarnya hal yang sama, dan kita perlu mempertahankan pemetaan semua ini ke OID yang benar. Jika pengembang ingin memberikan algoritma kustom (atau bahkan implementasi AES lain!), mereka harus memberi tahu kami OID-nya. Langkah pendaftaran tambahan ini membuat konfigurasi sistem sangat menyakitkan.

Mundur, kami memutuskan bahwa kami mendekati masalah dari arah yang salah. OID memberi tahu Anda apa algoritmanya, tetapi kami tidak benar-benar peduli tentang hal ini. Jika kita perlu menggunakan satu nilai entropis dengan aman dalam dua algoritma yang berbeda, tidak perlu bagi kita untuk mengetahui apa algoritma sebenarnya. Apa yang sebenarnya kita pedulikan adalah bagaimana perilaku mereka. Setiap algoritma sandi blok simetris yang layak juga merupakan permutasi pseudorandom yang kuat (PRP): memperbaiki input (kunci, mode rantai, IV, teks biasa) dan output ciphertext akan dengan probabilitas yang luar biasa berbeda dari algoritma sandi blok simetris lainnya yang diberikan input yang sama. Demikian pula, fungsi hash kunci yang layak juga merupakan fungsi pseudorandom (PRF) yang kuat, dan mengingat set input tetap outputnya akan sangat berbeda dari fungsi hash kunci lainnya.

Kami menggunakan konsep PRD dan PDF yang kuat ini untuk membangun header konteks. Header konteks ini pada dasarnya bertindak sebagai thumbprint yang stabil atas algoritma yang digunakan untuk operasi tertentu, dan memberikan kelincahan kriptografi yang diperlukan oleh sistem perlindungan data. Header ini dapat direproduksi dan digunakan nanti sebagai bagian dari proses derivasi subkunci. Ada dua cara berbeda untuk membangun header konteks tergantung pada mode operasi algoritma yang mendasar.

Enkripsi mode CBC + autentikasi HMAC

Header konteks terdiri dari komponen berikut:

[16 bit] Nilai 00 00, yang merupakan penanda yang berarti "enkripsi CBC + autentikasi HMAC".
[32 bit] Panjang kunci (dalam byte, big-endian) dari algoritma sandi blok simetris.
[32 bit] Ukuran blok (dalam byte, big-endian) dari algoritma sandi blok simetris.
[32 bit] Panjang kunci (dalam byte, big-endian) dari algoritma HMAC. (Saat ini ukuran kunci selalu cocok dengan ukuran hash.)
[32 bit] Ukuran hash (dalam byte, big-endian) dari algoritma HMAC.
EncCBC(K_E, IV, ""), yang merupakan output dari algoritma cipher blok simetris yang diberikan input string kosong dan di mana IV adalah vektor all-zero. Konstruksi K_E dijelaskan di bawah ini.
MAC(K_H, ""), yang merupakan output dari algoritma HMAC yang diberi input string kosong. Konstruksi K_H dijelaskan di bawah ini.

Idealnya, kita bisa melewati semua vektor nol untuk K_E dan K_H. Namun, kami ingin menghindari situasi di mana algoritma yang mendasarinya memeriksa keberadaan kunci yang lemah sebelum melakukan operasi apa pun (terutama DES dan 3DES), yang menghalangi penggunaan pola sederhana atau berulang seperti vektor all-zero.

Sebagai gantinya, kami menggunakan NIST SP800-108 KDF dalam Mode Penghitung (lihat NIST SP800-108, Sec. 5.1) dengan kunci, label, dan konteks panjang nol dan HMACSHA512 sebagai PRF yang mendasar. Kami memperoleh | K_E | + | K_H | byte output, lalu menguraikan hasilnya ke dalam K_E dan K_H diri mereka sendiri. Secara matematis, ini diwakili sebagai berikut.

( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")

Contoh: AES-192-CBC + HMACSHA256

Sebagai contoh, pertimbangkan kasus di mana algoritma sandi blok simetris adalah AES-192-CBC dan algoritma validasi HMACSHA256. Sistem akan menghasilkan header konteks menggunakan langkah-langkah berikut.

Pertama, biarkan ( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), di mana | K_E | = 192 bits dan | K_H | = 256 bits per algoritma yang ditentukan. Ini mengarah ke K_E = 5BB6..21DD dan K_H = A04A..00A9 dalam contoh di bawah ini:

5B B6 C9 83 13 78 22 1D 8E 10 73 CA CF 65 8E B0
61 62 42 71 CB 83 21 DD A0 4A 05 00 5B AB C0 A2
49 6F A5 61 E3 E2 49 87 AA 63 55 CD 74 0A DA C4
B7 92 3D BF 59 90 00 A9

Selanjutnya, komputasi Enc_CBC (K_E, IV, "") untuk AES-192-CBC yang diberikan IV = 0* dan K_E seperti di atas.

result := F474B1872B3B53E4721DE19C0841DB6F

Selanjutnya, komputasi MAC(K_H, "") untuk HMACSHA256 yang diberikan K_H seperti di atas.

result := D4791184B996092EE1202F36E8608FA8FBD98ABDFF5402F264B1D7211536220C

Ini menghasilkan header konteks lengkap di bawah ini:

00 00 00 00 00 18 00 00 00 10 00 00 00 20 00 00
00 20 F4 74 B1 87 2B 3B 53 E4 72 1D E1 9C 08 41
DB 6F D4 79 11 84 B9 96 09 2E E1 20 2F 36 E8 60
8F A8 FB D9 8A BD FF 54 02 F2 64 B1 D7 21 15 36
22 0C

Header konteks ini adalah thumbprint dari pasangan algoritma enkripsi terautentikasi (enkripsi AES-192-CBC + validasi HMACSHA256). Komponen, seperti yang dijelaskan di atas adalah:

penanda (00 00)
panjang kunci cipher blok (00 00 00 18)
ukuran blok cipher blok (00 00 00 10)
panjang kunci HMAC (00 00 00 20)
ukuran hash HMAC (00 00 00 20)
output (F4 74 - DB 6F) PRP cipher blok dan
output (D4 79 - end)HMAC PRF .

Catatan

Header konteks enkripsi mode CBC + Autentikasi HMAC dibangun dengan cara yang sama terlepas dari apakah implementasi algoritma disediakan oleh Windows CNG atau oleh jenis SymmetricAlgorithm dan KeyedHashAlgorithm terkelola. Ini memungkinkan aplikasi yang berjalan pada sistem operasi yang berbeda untuk menghasilkan header konteks yang sama dengan andal meskipun implementasi algoritma berbeda antara OS. (Dalam praktiknya, KeyedHashAlgorithm tidak harus menjadi HMAC yang tepat. Ini bisa berupa jenis algoritma hash bertanda kunci.)

Contoh: 3DES-192-CBC + HMACSHA1

Pertama, biarkan ( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), di mana | K_E | = 192 bits dan | K_H | = 160 bits per algoritma yang ditentukan. Ini mengarah ke K_E = A219..E2BB dan K_H = DC4A..B464 dalam contoh di bawah ini:

A2 19 60 2F 83 A9 13 EA B0 61 3A 39 B8 A6 7E 22
61 D9 F8 6C 10 51 E2 BB DC 4A 00 D7 03 A2 48 3E
D1 F7 5A 34 EB 28 3E D7 D4 67 B4 64

Selanjutnya, komputasi Enc_CBC (K_E, IV, "") untuk 3DES-192-CBC yang diberikan IV = 0* dan K_E seperti di atas.

result := ABB100F81E53E10E

Selanjutnya, komputasi MAC(K_H, "") untuk HMACSHA1 yang diberikan K_H seperti di atas.

result := 76EB189B35CF03461DDF877CD9F4B1B4D63A7555

Ini menghasilkan header konteks lengkap yang merupakan thumbprint dari pasangan algoritma enkripsi terautentikasi (enkripsi 3DES-192-CBC + validasi HMACSHA1), yang ditunjukkan di bawah ini:

00 00 00 00 00 18 00 00 00 08 00 00 00 14 00 00
00 14 AB B1 00 F8 1E 53 E1 0E 76 EB 18 9B 35 CF
03 46 1D DF 87 7C D9 F4 B1 B4 D6 3A 75 55

Komponen diuraikan sebagai berikut:

penanda (00 00)
panjang kunci cipher blok (00 00 00 18)
ukuran blok cipher blok (00 00 00 08)
panjang kunci HMAC (00 00 00 14)
ukuran hash HMAC (00 00 00 14)
output (AB B1 - E1 0E) PRP cipher blok dan
output (76 EB - end)HMAC PRF .

Enkripsi + autentikasi Mode Galois/Penghitung

Header konteks terdiri dari komponen berikut:

[16 bit] Nilai 00 01, yang merupakan penanda yang berarti "enkripsi + autentikasi GCM".
[32 bit] Panjang kunci (dalam byte, big-endian) dari algoritma sandi blok simetris.
[32 bit] Ukuran nonce (dalam byte, big-endian) yang digunakan selama operasi enkripsi terautentikasi. (Untuk sistem kami, ini diperbaiki pada ukuran nonce = 96 bit.)
[32 bit] Ukuran blok (dalam byte, big-endian) dari algoritma sandi blok simetris. (Untuk GCM, ini diperbaiki pada ukuran blok = 128 bit.)
[32 bit] Ukuran tag autentikasi (dalam byte, big-endian) yang dihasilkan oleh fungsi enkripsi terautentikasi. (Untuk sistem kami, ini diperbaiki pada ukuran tag = 128 bit.)
[128 bit] Tag Enc_GCM (K_E, nonce, ""), yang merupakan output dari algoritma cipher blok simetris yang diberikan input string kosong dan di mana nonce adalah vektor all-zero 96-bit.

K_E diturunkan menggunakan mekanisme yang sama seperti dalam skenario enkripsi CBC + autentikasi HMAC. Namun, karena tidak K_H ada permainan di sini, kami pada dasarnya memiliki | K_H | = 0, dan algoritma runtuh ke formulir di bawah ini.

K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")

Contoh: AES-256-GCM

Pertama, biarkan K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), di mana | K_E | = 256 bits.

K_E := 22BC6F1B171C08C4AE2F27444AF8FC8B3087A90006CAEA91FDCFB47C1B8733B8

Selanjutnya, komputasi tag Enc_GCM (K_E, nonce, "") autentikasi untuk AES-256-GCM yang diberikan nonce = 096 dan K_E seperti di atas.

result := E7DCCE66DF855A323A6BB7BD7A59BE45