4 trụ cột của Internet

· ~17 phút đọc
AWS & Security

1. Asymmetric algorithms: RSA và ECDSA

Mật mã bất đối xứng dùng một cặp khóa: Public Key có thể chia sẻ, Private Key giữ kín.

RSA có thể mã hóa HOẶC ký, tùy cơ chế. ECDSA THÌ chỉ ký. ECDHE: cách tạo private key dùng chung cho 2 server xa lạ.

RSA không phù hợp để mã hóa dữ liệu lớn vì chậm và giới hạn kích thước thông điệp; dữ liệu lớn thường dùng mã hóa đối xứng.

So theo vai trò: RSA-PSS ~ ECDSA là hai lựa chọn ký số. RSA key transport ~ ECDHE là hai cách thiết lập bí mật cho kết nối, nhưng cách hoạt động khác nhau.

RSA mã hóa và giải mã: Dữ liệu thực tế

Mục tiêu: che giấu nội dung. Chạy bằng RSA-OAEP, khóa 2048 bit.

Public key:

1
2
3
4
5
6
7
8
9
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtpWqPMY/OqV9eMN/abqf
wFNS4My7kfP+zFXeBapaOHAcRdqPdjsFyISH8aYr9eWnLd4280o/LrkxZF6HJrI9
xqV0QzzCaJ8k39NHI92bsx6T61JtT6RqJRIXhP4ZSGbsV/E3tEuXl0042GDyHm/o
u86SCvFy9Rs0swQfCI84LnWC6cdXq00mS0XzSG3/kT60avC6V51lpO4201h6tC+w
I/HbSgQD+jCeqp+jJfX7eDfELBlnbnHF+eD0+5o8B/zLexkjy6s0jwBfBBQSdR0R
3fzuYqWJdK/OAwyrg/AzifA1Qth83m1Z7T5jmwTvoAlV98VVJ6XLCTp/8ndM7r0u
nwIDAQAB
-----END PUBLIC KEY-----

Private key: (sample thôi nhé :D)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC2lao8xj86pX14
w39pup/AU1LgzLuR8/7MVd4Fqlo4cBxF2o92OwXIhIfxpiv15act3jbzSj8uuTFk
Xocmsj3GpXRDPMJonyTf00cj3ZuzHpPrUm1PpGolEheE/hlIZuxX8Te0S5eXTTjY
YPIeb+i7zpIK8XL1GzSzBB8IjzgudYLpx1erTSZLRfNIbf+RPrRq8LpXnWWk7jbT
WHq0L7Aj8dtKBAP6MJ6qn6Ml9ft4N8QsGWduccX54PT7mjwH/Mt7GSPLqzSPAF8E
FBJ1HRHd/O5ipYl0r84DDKuD8DOJ8DVC2HzebVntPmObBO+gCVX3xVUnpcsJOn/y
d0zuvS6fAgMBAAECggEAA0Fo+C+j7cYq8+RIeU3eSkNUNWAKvomaqoKSxYgnyhA5
8NPYiv9lnar/R+4lgftPWv5HlzZkwoqldCQoI69tHLBKzqo8iwZYM5JEjrlJoBVQ
Sq0OGivU2KzmLFMEEGPBJTBGROz4Yz8KktVfJneEFb/XjwyGiDUTcVdKiZBELHH+
5qNsN+r9djmEA0kfM51d2+tgP9Vbq97JN0HjIR8xqI356pBrXwCkZ4vrXNxLaMtG
kvs9OwrtHirnPEZHCias8xq4m2TVeKhNUT3kxdlciT9OFRixfnq7dYxQsLZnNFU+
EVzKYTAMKHtoU5KF+DSfd/gOooDVl47Qe9zT5vKlAQKBgQDb6zelOm9lfSSUzaSM
1Si/58GrAPZlGb3xZxTxqURqGjDKsKdH4YZMJ1/YrGo7xLROEKhdXmEKBkWskv/P
SgpIyx42YcJYrIeR+O5aJChQ/NSCKtuCGV9ISTeOULYUxhs08jX+MsC9l9X8oScq
Pl9rXV0rN653a1qnx3rjVboQzwKBgQDUimEJG0ciVeQBH3XUMcvJ0TJ4QpzFJxnk
Se8A2N6DUXVHC7Szk6NiIMwub+xRVumaPhjHBYPnpPewdgArN37q3ufjE8YVkd8h
al7wocB4VWRGkL18JVexPxTUAeKB1Nn3gch3Zugyedc5g7MFC+sRjpfKYlqBGVhq
c4ylhzhZMQKBgQCamDFXz0o7t8sdZ6pC7h1lOg/knBqZW40ww9vvPaRASgT+l0wg
taLoqc0wzZMoTNDLB96zNANXPq1/8R4uo8ezAEZOyE4Mc8whizJS35QPyovArUv9
msRmVkHdo1M8Kz846wOVnCvtm2zr2IVlps8A9HLoTI4ymJ7zzsDOSpcv9QKBgQCN
Mx2CIkggzHT8Nf1eqnJbsopYEND7vZ1a569Lncg975j9SQ6UmsnZgDaFxz91TktF
eGmXltdpxlPzPIGiNG0x9kKRvmpDnDRji7plHOC0UO6cXr4zws8+Zs0ch+AGJvVj
lCotAQXTutQ8Vn1RJfjWIig/gRXlXIQ7vGY89dd+kQKBgGBrxQVl+ro78Sd7Z902
2VvJ0y30Iu04pY52pjMN1AKPtx0XFpzhKLTdqtqDoJYOZkZyl5gtltlHwOtARIZu
iWkLyz3soe6F8C1Fn2ULEsb5lsZOBFbApPhBChSh9CzZk3CJnyVwE6KCK9xgsztB
ZGzSwivxTEeVmoJwLvHcNUFA
-----END PRIVATE KEY-----

1. Câu gốc Hudson muốn gửi:

1
Hudson chuyển tiền cho Alice 100 dollars

2. Hudson mã hóa bằng Public Key của Alice (bằng cách nào đó Alice đưa được cho Hudson Public key này):

1
Câu gốc + Public Key của Alice -> RSA-OAEP -> 256 byte bản mã

Result:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
0c 9a 21 b2 82 92 5d eb 9f c3 3d 2f 76 5e 34 d7
dd c9 8f ba dd 39 92 97 50 66 ab 97 0d 4e b9 53
e8 58 3e f6 c3 7d f4 a2 d3 1a bb 34 d0 87 4f 84
37 c9 7b 6b 08 d1 af 4a 75 36 c1 51 34 99 61 74
05 89 4c 3f b1 a4 39 62 41 9a ff f6 05 bf fe 35
55 dc a0 0f 2f ee f9 a8 92 7b 7e 08 2e 43 6c e7
e6 23 d6 7f 43 bc 3d cb 85 30 47 53 20 89 bb 6c
ed cd fd e6 5a 41 b6 29 cc 9f e9 e8 74 69 71 71
99 ce f9 19 8f 0f 79 d7 e6 0c 89 7e d3 ca 67 4a
ca 31 2a f9 81 a6 86 92 18 9e eb 4b 1d ab a3 6c
1c b7 c4 02 61 63 b2 7d 9a 55 9a 2b 95 d1 06 29
e2 13 59 20 1b 65 74 8a da c4 33 a3 94 53 5f 8b
1a 36 65 d4 ae 5b 7f 8e 78 e2 d0 93 00 3c bd 4d
5d 1e 0c 35 7a cf 20 b0 2d 7b 75 f7 02 7b 1c 69
96 23 71 5c ee 21 a3 2a 74 3c 26 60 7a 43 bc 11
84 89 08 e8 28 62 bc 62 22 65 2a e4 6f fd 4f fa

3. Alice giải mã bằng Private Key của mình:

1
2
3
256 byte bản mã trên + Private Key của Alice
    ↓ Giải mã RSA-OAEP
Hudson chuyển tiền cho Alice 100 dollars

RSA ký và verify: Dữ liệu thực tế

Mục tiêu: kiểm tra chữ ký và phát hiện câu bị sửa. Chạy bằng RSA-PSS, khóa 2048 bit và SHA-256.

Public key:

1
2
3
4
5
6
7
8
9
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4NRHFdNc2oStjpRyItyl
0dTfs2BDpHBpRC2WnTOri1Y/u8TR4uZSYP9R/eSkqbrAW0Ppr1KVlp7SVF8IwVWZ
3z0vN07wTDoZ7fzZS2spHxp95SAO5yi/T5ju0AQpYBlLk8ZwGhe5zxdsVhiFPJd+
2bsiZhiSeZwrk2LK+MF5MNooiC7+6czn0EZzzt7GiSWVeTfNIW78ZeOwEWITSUiO
XVpWC33Pis+AlOJShG01xUOzVzntC67HOaWMOFPL1x5nKbp80obaPpTuHSUKc3QS
vIHB2bNZY7PVEyQDt4DKpqpL9MlbXlmbn1h5d/HPzrCyanag0NQkZxo3WckTM1/1
+QIDAQAB
-----END PUBLIC KEY-----

Private key:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDg1EcV01zahK2O
lHIi3KXR1N+zYEOkcGlELZadM6uLVj+7xNHi5lJg/1H95KSpusBbQ+mvUpWWntJU
XwjBVZnfPS83TvBMOhnt/NlLaykfGn3lIA7nKL9PmO7QBClgGUuTxnAaF7nPF2xW
GIU8l37ZuyJmGJJ5nCuTYsr4wXkw2iiILv7pzOfQRnPO3saJJZV5N80hbvxl47AR
YhNJSI5dWlYLfc+Kz4CU4lKEbTXFQ7NXOe0Lrsc5pYw4U8vXHmcpunzShto+lO4d
JQpzdBK8gcHZs1ljs9UTJAO3gMqmqkv0yVteWZufWHl38c/OsLJqdqDQ1CRnGjdZ
yRMzX/X5AgMBAAECggEAChuxKHuMwKxXa0IkUYnvEJyMBDIPSHzfVrff/ihdDZIu
omAKebOWP5MrGgmmF5V0YYYPoxjI7fEtDqsJJzwUg3NqRIfRiPPRx5/nGxtxyVq1
D1CeKulrlIYRMpwFSjNI8RdqYdnwOi3Y6pQGpX9ALkTaGpH/P+V0FhfKfV2hd785
oIxGcV3PdSjNuKKPKVwpa77MIYNkZl1AsBLI6UMy9TpwTEkOBRWpOm31HkMlM1Ng
mM4irrat+YmiRZZw/LrFUAInUY8cUDT+ci040Bvf/dwm8Nu1caWlSz5TI4uVqs6O
UG1V1mKRVv+o7OMCyl1xu/a9ckeu00l3KBPqgOU6wQKBgQD02vNWXu0RnTR6EJCT
FKGpC35XH0VkrcPjaFhrz4insWmePddiX5DTtos3ksc4cv6vpQ8m99JeyqzBZuYV
Z99EFxuncMpRDkoifr5K6GwJPlkGocdDBC6MqILKVFjSuNXDZRmPYSkM7GLzYSmv
lm/eUTICqbzoPl64P6oQT6RP8QKBgQDrD/vYAve+qCpbRkvJNF4mCjmJcXUO0C1v
fmFzV4IbuElhKWk8Bk3PIsmn738zGrOJOAh/47JMAQMl2hkrUggX1zISRKMMAacj
cUBNsq1SoK64yOqgqNeFw+9XjAPZqOmtysEFI4NhbWjS46gjOlyJFVxNFuA6pCri
lDqAqzIOiQKBgDCEehcxNBR7a/yL77nVKrtOVbh5r8xlSh1zfaHPO6rO0rjSVC1f
9lidITTf1q3uy1yOflQgYwT5cAXal9jB/lGFqqshBFXPWQ1AxAAf0dh7DDTuNYen
+nlQoqno0Ljgeyr+i3QHspSm+mxzYkkyq/QHbrtsWsxCH46uvsoAnfRhAoGAKI4S
altguQE0hZjkPGuPjsqW0LLFem/KVwEb+RVw+i1aY6wMXvHLfOBIoHO+o2eI8DS9
qqrzOQ+3plExpHq7sLlNBz/WTZz/ZCsG6CDarHXSj0kCygM3Y/nBEn6yr1voLTbd
BHDzGt0Qh8oFWUaZboFD8nzu5M8sIvll+osO0NkCgYEAnInJ6z21z1m2VVztxLZL
NFj/nNjWKmuRilWdr9LT1XBHsSiU+d6RZ21tIFgvov7NW5EIuRKPCwYinMljM8+l
H9/b+wDM+QrtsYQ+o774JcaTu7KjgmpUQ3bzsXLUOCm1PwRFVbkaiUecn04lmwqL
rmCnc2HQp/Dg8fmIcR/Lv6E=
-----END PRIVATE KEY-----

1. Câu Hudson muốn ký:

1
Hudson chuyển tiền cho Alice 100 dollars

2. SHA-256 tạo hash, tức “dấu vân tay” của câu, chưa phải chữ ký. Kết quả thật, dạng hex:

1
2
SHA-256("Hudson chuyển tiền cho Alice 100 dollars", dùng UTF-8)
= ed1b347a7c9928ded4219a72b3d3f51b563c5eaa5df7bebc30791dbc09e926c5

3. Ký bằng Private Key:

1
2
3
Câu gốc + Private Key của Hudson
    ↓ RSA-PSS (dùng hash ở bước 2)
Chữ ký dài 256 byte

Result:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
de ce 15 3b 7f 79 03 b7 a3 e4 04 0d d7 cc 6d c8
02 13 0f 27 25 a9 4e 23 ea d7 0c 0b 61 f7 13 c0
c8 50 1b 63 81 bb 01 49 6d 4e 29 09 d4 1f c0 83
a1 79 05 7a e8 a2 9b 63 66 c8 37 b2 a6 89 bf ba
3a f4 06 a1 78 f1 02 9c 30 50 ed 9b fe 6c 26 d6
00 a4 9b 0c ae 8b 50 a3 04 3e fb 8f 09 69 1d 05
20 97 c2 6d 9d e7 69 65 36 31 d5 17 1b 1d bc 06
47 eb ea ed 46 73 d7 74 17 a2 6f f0 ac a7 af 79
88 41 d0 c2 a4 93 7c 28 46 22 69 1e 6d 99 a6 d0
af 39 18 7a d0 0f a1 f5 b8 28 e5 fc f4 de ea 42
41 5b 3a 2d 04 ad 7e 38 18 cf db b6 ea 8a 14 4f
33 31 51 6d 06 55 d7 74 bd eb b1 1c be 79 3b e9
31 ba 14 87 c6 27 a2 13 e6 2a fb f2 ea 79 53 94
7a 7f e1 bc 8f 28 95 cc 0d 6e ee b0 8c 0d a6 c0
40 51 c9 30 da 4a 01 2b 1f d2 19 d4 c5 df a8 91
aa 97 57 c5 9b 1d a3 40 97 90 c3 82 22 a8 0f e1

4. Alice kiểm tra bằng Public Key của Hudson:

1
2
3
Câu nhận được + chữ ký + Public Key của Hudson
    ↓ Verify RSA-PSS (tính lại hash của câu để kiểm tra chữ ký)
true hoặc false

Giữ nguyên Public Key và chữ ký từ lần chạy local, kết quả:

Câu Alice nhận được Verify
Hudson chuyển tiền cho Alice 100 dollars true: chữ ký hợp lệ
Hudson chuyển tiền cho Alice 1000 dollars false: câu bị sửa, hash đổi, chữ ký cũ không còn hợp lệ

Ký không che giấu câu gốc. Verify kiểm tra chữ ký, không “giải mã chữ ký” để lấy lại câu.

Chữ ký số với ECDSA

ECDSA chỉ ký, không mã hóa. Ví dụ chạy thật với P-256 và SHA-256.

1. Cặp khóa thử nghiệm của Hudson, hiển thị hex. Private Key chỉ hiện đầu/cuối; phần giữa đã lược bỏ, không phải khóa đầy đủ:

1
2
Private Key: e35f8f23...7b3e0608
Public Key:  044a046c26e4619efb326eb3f85f7c81c7d2cb63ad5719e2113ee4f318ea6f48238f8efc090f66afa7ca9897443e34f841f2d65358fbd98026c07dc1140edc5571

2. Câu gốc và hash SHA-256 của nó:

1
2
3
Hudson chuyển tiền cho Alice 100 dollars
    ↓ SHA-256, dùng UTF-8
ed1b347a7c9928ded4219a72b3d3f51b563c5eaa5df7bebc30791dbc09e926c5

3. Ký bằng Private Key:

1
2
3
Câu gốc + Private Key đầy đủ của Hudson
    ↓ ECDSA (dùng hash ở bước 2)
Chữ ký

Đủ 64 byte chữ ký thật, dạng hex: 32 byte đầu biểu diễn số nguyên gọi là r, 32 byte sau biểu diễn số nguyên gọi là s.

1
2
3
4
b7 78 07 94 17 35 3a dd 99 5f d3 13 6d 83 fa 65
c7 6d 37 2b ff 3b 58 8b 4a 48 b2 b7 c9 c4 14 f9
d9 ec 33 5f 95 fb 01 b2 ec e0 83 38 e9 b1 a6 d6
1f 87 be 84 23 a0 54 d5 eb 47 95 0a 82 e8 99 01

4. Alice verify bằng Public Key ở bước 1:

1
2
3
Câu nhận được + 64 byte chữ ký trên + Public Key của Hudson
    ↓ Verify ECDSA
true hoặc false

Kết quả chạy thật, giữ nguyên Public Key và chữ ký:

Câu Alice nhận được Verify
Hudson chuyển tiền cho Alice 100 dollars true
Hudson chuyển tiền cho Alice 1000 dollars false

Giống RSA-PSS: Private Key ký, Public Key kiểm tra; chữ ký không che giấu câu gốc. ECDHE là thỏa thuận khóa, không phải ký.

2. Mã hóa đối xứng: AES

Nếu bất đối xứng giống một ổ khóa công khai và một chìa khóa riêng, thì đối xứng giống hai người cùng giữ bản sao của một chìa khóa bí mật.

1
2
Dữ liệu gốc + Secret Key → Mã hóa → Dữ liệu đã mã hóa
Dữ liệu đã mã hóa + cùng Secret Key → Giải mã → Dữ liệu gốc

AES (Advanced Encryption Standard) là một thuật toán mã hóa đối xứng phổ biến, hỗ trợ khóa 128, 192 hoặc 256 bit.

Điểm mạnh: Rất nhanh, phù hợp để mã hóa lượng dữ liệu lớn như trang web, ảnh, video hoặc file tải xuống.

Câu hỏi còn lại: Làm sao hai bên có được cùng một Secret Key mà không để lộ nó khi truyền qua mạng? Đây là lúc cơ chế trao đổi khóa như ECDHE xuất hiện.

Trong HTTPS, ta thường gặp AES-GCM, không chỉ tên AES:

  • AES là thuật toán mã hóa khối.
  • GCM là chế độ giúp vừa mã hóa vừa xác thực dữ liệu, phát hiện việc sửa đổi trái phép.
  • GCM cần nonce không bị lặp lại với cùng một khóa. Thuật toán mạnh không cứu được cách sử dụng sai.

TLS 1.3 cũng hỗ trợ ChaCha20-Poly1305 cho vai trò mã hóa có xác thực, nên không phải kết nối HTTPS nào cũng dùng AES.

AES mã hóa và giải mã: Dữ liệu thực tế

Chạy thật bằng AES-256-GCM. Khóa dưới đây là dữ liệu minh họa công khai, không dùng cho dữ liệu thật. Các chuỗi byte được hiển thị bằng hex.

1. Đầu vào:

1
2
3
Câu gốc: Hudson chuyển tiền cho Alice 100 dollars
Key:     000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
Nonce:   000102030405060708090a0b

Key là khóa chung 32 byte. Nonce là giá trị 12 byte cho lần mã hóa này, không được lặp với cùng Key; nó không cần giữ bí mật.

2. Mã hóa:

1
2
3
4
5
6
7
Câu gốc (UTF-8) + Key + Nonce → AES-256-GCM

Bản mã (44 byte):
0f77b268aa8be278e534ee6a0a6a164df7bf668f71157f1f5008c5c4710063d721219ecc8fa57df418c50d9e

Tag (16 byte):
6eea2c28cd439a4dbe74e1b69af27138

Tag là mã xác thực, dùng để kiểm tra dữ liệu có bị sửa. Nó là một phần của AES-GCM, không phải chữ ký số.

3. Giải mã bằng cùng Key:

1
2
3
Bản mã + Key + Nonce + Tag
    ↓ Giải mã và kiểm tra AES-256-GCM
Hudson chuyển tiền cho Alice 100 dollars

Kết quả chạy thật: khớp câu gốc. Đổi byte đầu bản mã từ 0f thành 0e, giữ nguyên các giá trị khác → lỗi xác thực, không chấp nhận dữ liệu.

3. Hashing: SHA

Hashing giống như lấy dấu vân tay của dữ liệu: đưa một thông điệp vào hàm băm và nhận lại một giá trị có độ dài cố định.

Ví dụ, SHA-256 luôn tạo ra kết quả dài 256 bit, dù đầu vào là một câu ngắn hay một file lớn.

1
Dữ liệu → SHA-256 → Giá trị hash 256 bit

SHA-256: Đổi một ký tự, xem kết quả

Kết quả chạy thật với text UTF-8, hash hiển thị bằng hex:

1
2
3
4
5
SHA-256("Hudson chuyển tiền cho Alice 100 dollars")
= ed1b347a7c9928ded4219a72b3d3f51b563c5eaa5df7bebc30791dbc09e926c5

SHA-256("Hudson chuyển tiền cho Alice 1000 dollars")
= 137ccd16f2ed4251dfac88c35ce57c6bbb57f09f94a8cee7a9c3b96de629e5e9

Không có Key, không có bước giải mã. Thêm một số 0 làm hash đổi; cả hai kết quả vẫn dài 32 byte, tương ứng 64 ký tự hex.

  • Cùng đầu vào thì luôn có cùng kết quả.
  • Thay đổi rất nhỏ ở đầu vào thường khiến kết quả thay đổi mạnh.
  • Hàm băm mật mã được thiết kế để rất khó tìm đầu vào từ hash hoặc tìm hai đầu vào khác nhau có cùng hash.

Hashing không phải mã hóa: Không có Private Key hay Secret Key để “giải mã” hash về dữ liệu ban đầu. Tuy nhiên, nếu đầu vào dễ đoán, người ta vẫn có thể thử từng giá trị rồi so sánh hash.

Và hash không bảo đảm mỗi dữ liệu có một dấu vân tay duy nhất tuyệt đối. Va chạm vẫn tồn tại về mặt toán học; yêu cầu an toàn là việc tìm ra chúng phải không khả thi về mặt tính toán.

Một giới hạn quan trọng: hash đơn thuần không xác thực người gửi. Nếu hacker sửa được cả file lẫn giá trị hash đính kèm, họ có thể tính lại hash cho file giả. Muốn chống việc đó, cần nguồn hash đáng tin cậy, chữ ký số hoặc cơ chế có khóa như HMAC.

Trong TLS 1.3, hàm băm được dùng để tạo hash của dữ liệu bắt tay và làm nền tảng cho HKDF, cơ chế dẫn xuất khóa. Nó hỗ trợ quá trình xác thực và tạo khóa, chứ không trực tiếp mã hóa trang web.

SHA là tên một họ thuật toán, không phải tất cả đều còn an toàn cho mọi mục đích. SHA-256 thuộc SHA-2; không nên nhầm nó với SHA-1, vốn đã bị phá khả năng chống va chạm.

4. Trao đổi khóa: ECDHE

Diffie-Hellman (một biến thể hiện đại là ECDHE) là thuật toán giúp 2 người, ví dụ máy của bạn và Server, tự tạo ra cùng một bí mật chung để dẫn xuất khóa mã hóa đối xứng, mà KHÔNG CẦN gửi bí mật chung đó qua mạng.

Dù hacker có nghe lén và capture lại 100% dữ liệu truyền qua truyền lại, việc tính ra bí mật chung đó vẫn không khả thi về mặt tính toán với các phương pháp tấn công cổ điển hiện biết, nếu dùng tham số đủ mạnh và triển khai đúng. Đây không phải bảo đảm tuyệt đối: Diffie-Hellman tự nó không ngăn được tấn công đứng giữa chủ động (MITM) nếu thiếu xác thực.

ECDHE: Hai bên tính ra cùng bí mật

Chạy thật với P-256, mỗi bên tạo một cặp khóa mới cho lần trao đổi này. Dữ liệu dưới đây ở dạng hex; Private Key chỉ hiện đầu/cuối, tính toán dùng khóa đầy đủ.

1. Hai cặp khóa thử nghiệm:

1
2
3
4
5
6
7
Hudson:
  Private Key: f9e2b2ae...8ecd68f5
  Public Key:  04b5d97f04a337c163034c189ccb61fd5c7d794a18a9ff8c3b5daa26c2936c15a169a48f03a0f86ca7bfd06b7519391337f1e7e6b268d10bc42b35417e27570987

Alice:
  Private Key: 10bb7a10...28a99d9f
  Public Key:  042acb6bdf022623d37d22fd331b714958ca2851a3176da0b30a589caedc078a19f29623e0520c5374ff58750b0a17f88734c4790b00c44a11d9e3461d6bd94c37

2. Trao đổi Public Key:

1
2
Hudson gửi Public Key của Hudson → Alice
Alice gửi Public Key của Alice   → Hudson

3. Mỗi bên tự tính, kết quả thật:

1
2
3
4
5
6
7
Private Key Hudson + Public Key Alice → ECDH → bí mật phía Hudson:
0969887ca4b6a6ae4e5b015090ce4dc1920e3182249aa7ae378ab3a4b901bee9

Private Key Alice + Public Key Hudson → ECDH → bí mật phía Alice:
0969887ca4b6a6ae4e5b015090ce4dc1920e3182249aa7ae378ab3a4b901bee9

Hai bí mật giống nhau: true

Hai bên tính ra cùng 32 byte bí mật, không truyền bí mật đó cho nhau. Đây là đầu vào để dẫn xuất khóa mã hóa, không phải chữ ký hay bản mã. Chữ E cuối trong ECDHE chỉ việc dùng cặp khóa tạm thời cho lần trao đổi.

Ý tưởng cốt lõi: Ví dụ về màu sắc

Hãy tưởng tượng Diffie-Hellman hoạt động giống như việc trộn màu sơn:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Máy bạn]                                                    [Server]
   │                                                            │
   ├────────── Chốt chung 1 màu công khai (VD: Vàng) ───────────┤
   │                                                            │
   │ 1. Tự chọn 1 màu bí mật (Đỏ)   1. Tự chọn 1 màu bí mật (Xanh)│
   │ 2. Trộn: Vàng + Đỏ = Cam       2. Trộn: Vàng + Xanh = Lục  │
   │                                                            │
   ├── Gửi màu Cam qua mạng ──────────>                         │
   │                         <────────── Gửi màu Lục qua mạng ──┤
   │                                                            │
   │ 3. Lấy Lục + Đỏ (bí mật)       3. Lấy Cam + Xanh (bí mật)  │
   │    ==> Ra màu Nâu              ==> Ra màu Nâu              │
   ▼                                                            ▼
 [KẾT QUẢ: Cả 2 cùng có màu NÂU làm bí mật chung mà không bao giờ gửi màu Nâu đi]
  • Hacker thấy gì trên mạng? Thấy màu Vàng (công khai), màu Cam, màu Lục.
  • Tại sao Hacker thua? Trong mô hình minh họa này, từ Cam và Lục rất khó (gần như không thể) bóc tách ngược lại để tìm ra màu Đỏ hay Xanh ban đầu. Vì thiếu màu bí mật, Hacker không dễ pha ra màu Nâu. Màu sơn chỉ là phép ví von; độ an toàn thực tế dựa trên các bài toán khó trong nhóm toán học được chọn.

ECDHE giải thích từng ký tự là gì?

Tên gọi ECDHE ghép từ 3 thành phần:

  1. DH (Diffie-Hellman): Tên của 2 nhà khoa học công bố cơ chế trao đổi khóa này từ năm 1976.
  2. EC (Elliptic Curve - Đường cong Elliptic): Thay vì dùng lũy thừa modulo số nguyên lớn như DH truyền thống, ECDHE dùng các phép toán trên điểm của đường cong Elliptic trên trường hữu hạn. Nó đạt mức an toàn tương đương với khóa nhỏ hơn nhiều, giúp giảm lượng dữ liệu trao đổi; hiệu năng CPU còn tùy thuật toán và cách triển khai.
  3. E (Ephemeral - Ngắn hạn/Tạm thời):
    • Mỗi lần bắt tay HTTPS có trao đổi ECDHE mới, mỗi bên tạo một cặp khóa Diffie-Hellman mới và xóa khóa bí mật tạm thời khi không còn cần. Không phải mỗi lần vào web đều tạo kết nối hay bắt tay mới.
    • Tác dụng (Forward Secrecy): Dù sau này lộ Private Key dùng để xác thực Server, hacker cũng không thể chỉ dựa vào khóa đó để giải mã lại các phiên ECDHE trong quá khứ, nếu các bí mật tạm thời đã được xóa an toàn.

5. Honor list algo

Bcrypt: Băm mật khẩu

bcrypt được thiết kế để lưu mật khẩu, không phải băm dữ liệu thông thường như SHA-256. Cùng mật khẩu, salt và cost thì kết quả luôn giống nhau.

Hai điểm chính:

  • Salt riêng cho mỗi lần tạo hash: Thư viện sinh salt ngẫu nhiên. Cùng mật khẩu 123456 nhưng salt khác → chuỗi lưu khác, chống việc dùng chung bảng băm sẵn để dò hàng loạt tài khoản.
  • Cố tình chậm: Cost điều chỉnh lượng tính toán. Cost 10 tương ứng 2^10 = 1.024 vòng của bước mở rộng khóa; tăng cost thêm 1 thì công việc xấp xỉ gấp đôi. Thời gian thực tế tùy máy, không cố định 100 hay 300 ms.

Lưu một chuỗi gồm cả cấu hình, salt và hash, không cần cột salt riêng. Cấu trúc minh họa, tổng 60 ký tự:

1
2
3
$2b$10$<salt: 22 ký tự><hash: 31 ký tự>
 └─┬──┘
 phiên bản bcrypt + cost

Salt là 16 byte ngẫu nhiên, được biểu diễn thành 22 ký tự trong chuỗi bcrypt.

Khi đăng nhập:

1
2
3
4
5
Mật khẩu vừa nhập + chuỗi bcrypt trong DB
    ↓ compare đọc salt và cost từ chuỗi đã lưu
Băm lại mật khẩu bằng đúng salt và cost đó
    ↓ So sánh với kết quả đã lưu
true / false

Salt không cần giữ bí mật. Nó chống tái sử dụng bảng tra cứu giữa các salt khác nhau; cost làm mỗi lần đoán mật khẩu tốn công hơn. Nếu lộ DB, mật khẩu yếu vẫn có thể bị đoán, bcrypt không khiến brute-force trở thành bất khả thi.

Ghép lại: Khi bạn mở một trang HTTPS

Trong một lần bắt tay TLS 1.3 dùng chứng chỉ và ECDHE, các cơ chế phối hợp như sau. Đây là cách tách vai trò để dễ hiểu, không phải thứ tự chính xác của từng gói tin:

  1. Xác thực Server: Server dùng Private Key tương ứng với Certificate để ký dữ liệu bắt tay, ví dụ bằng ECDSA hoặc RSA-PSS. Trình duyệt kiểm tra chữ ký, chuỗi chứng chỉ và tên miền để xác minh “Tôi đúng là Google, không phải giả mạo”.
  2. Thỏa thuận bí mật: Hai bên chạy ECDHE để tự suy ra cùng một bí mật chung mà không truyền bí mật đó qua mạng.
  3. Dẫn xuất khóa: TLS dùng HKDF dựa trên hàm băm như SHA-256 hoặc SHA-384, kết hợp bí mật chung với ngữ cảnh bắt tay để dẫn xuất các khóa. Hai chiều truyền có khóa riêng, không dùng một khóa duy nhất cho mọi việc.
  4. Truyền dữ liệu: AES-GCM hoặc ChaCha20-Poly1305 mã hóa và xác thực dữ liệu web/video với tốc độ cao.
Trụ cột Ví dụ Vai trò chính
Mật mã bất đối xứng RSA-OAEP, RSA-PSS, ECDSA Mã hóa bằng RSA-OAEP; ký bằng RSA-PSS hoặc ECDSA. Trong TLS 1.3, RSA/ECDSA đảm nhiệm chữ ký, không vận chuyển khóa phiên bằng RSA
Mã hóa đối xứng AES-GCM Mã hóa và xác thực dữ liệu với tốc độ cao
Hashing SHA-256 / SHA-384 Tạo dấu vân tay dữ liệu, làm nền tảng cho HMAC và HKDF
Trao đổi khóa ECDHE Thỏa thuận bí mật chung để dẫn xuất khóa, không gửi bí mật đó qua mạng

Tóm lại: RSA và ECDSA nằm chung trong trụ cột mật mã bất đối xứng, với chức năng tùy cơ chế; AES bảo vệ dữ liệu lớn; SHA tạo dấu vân tay dữ liệu; ECDHE giúp hai bên thống nhất bí mật chung. Bốn mảnh ghép phối hợp để bảo vệ một kết nối HTTPS.

Home