Bộ Thông tin và Truyền thông

Cục Chuyển đổi số quốc gia

Danh mục điện tử dùng chung của các cơ quan nhà nước phục vụ phát triển Chính phủ điện tử tại Việt Nam (14/04/2020)
Bộ TT&TT: Triển khai QCVN số 102:2016/BTTTT về cấu trúc mã định danh và định dạng dữ liệu gói tin phục vụ kết nối các hệ thống văn bản quản lý và điều hành (Cập nhật ngày 21/5/2018) (13/09/2016)
Bộ Thông tin và Truyền thông: Giải thích các tiêu chuẩn kỹ thuật về ứng dụng CNTT trong cơ quan nhà nước (Cập nhật ngày 24/8/2017) (21/11/2013)

Cục Chuyển đổi số quốc gia > Bài học kinh nghiệm > Góc công nghệ

Tiêu chuẩn ECDHE

ECDHE là viết tắt của Elliptic Curve Diffie Hellman Ephemeral và là một cơ chế trao đổi khóa dựa trên đường cong Elliptic. Một giao thức thỏa thuận khóa, cung cấp cho hai bên với cặp khóa công khai để thiết lập bí mật được chia sẻ (được sử dụng trực tiếp như một khóa) một cách an toàn trên kênh công khai...

Ngày đăng : 09/12/2019 Xem với cỡ chữ

Bản in

I. Giới thiệu

Một số giải pháp đã được đề xuất cho một đường cong hình elip xác thực trao đổi khóa Diffie-Hellman bằng cách sử dụng các phím phù du và các khóa tĩnh. Tuy nhiên, các giải pháp này phụ thuộc vào (X) máy chủ / người nhận khóa công khai ECC tạm thời từ thiết bị / người gửi đến bản ghi (Y) hoặc hoạt động với khóa ECC riêng tĩnh tương ứng với khóa chung tĩnh được ghi bởi người gửi. Điều này có thể làm giảm khả năng mở rộng và bảo mật của các mạng hỗ trợ các thiết bị IoT, vì mỗi máy chủ / người nhận cũng cần ghi lại và hoạt động trên khóa riêng ECC tĩnh tương ứng với khóa chung ECC tĩnh được ghi bởi thiết bị / người gửi. Nói cách khác, bảo mật tổng thể của các hệ thống sử dụng các giải pháp được đề xuất cho trao đổi khóa ECDHE đã được xác thực có thể bị giảm với ang triệu thiết bị và ang chục máy chủ có tuổi thọ dự kiến trong một thập kỷ hoặc lâu hơn, trong đó các máy chủ ghi lại và hoạt động với ECC tĩnh.

II. Đặc điểm của Thuật toán chữ ký số dựa trên đường cong Elliptic Mã hóa bằng ECDH

ECDH là một biến thể của thuật toán Diffie-Hellman cho các đường anglip. Nó thực sự là một giao thức thỏa thuận khóa, hơn cả một thuật toán mã hóa. Điều này về cơ bản có nghĩa là ECDH định nghĩa (trong một chừng mực nào đó) cách các khóa nên được tạo và trao đổi giữa các bên. Làm thế nào để thực sự mã hóa dữ liệu bằng các khóa như vậy. Vấn đề đó giải quyết là như sau: hai bên (Alice và Bob thông thường) muốn trao đổi thông tin một cách an toàn, để bên thứ ba (Người đàn ông ở giữa) có thể chặn họ, nhưng không thể giải mã chúng. Đây là một trong những nguyên tắc đằng sau TLS, ví dụ sau đưa ra giúp giải thích rõ hơn.

Đây là cách nó hoạt động:

1. Đầu tiên, Alice và Bob tạo khóa chung và khóa riêng. Chúng tôi có khóa riêng d_A và khóa chung H_A=d_AG cho Alice, và khóa d_B và H_B=d_BG cho Bob. Lưu ý rằng cả Alice và Bob đều đang sử dụng cùng một tham số miền: cùng một điểm cơ sở G trên cùng một đường anglip trên cùng một trường hữu hạn.

2. Alice và Bob trao đổi khóa công khai của họ H_A và H_B qua một kênh không an toàn. Người đàn ông ở giữa sẽ chặn H_A và H_B, nhưng sẽ không thể tìm ra d_Ahoặc d_B nên không giải quyết vấn đề logarit rời rạc.

3. Alice tính toán S=d_AH_B (sử dụng khóa riêng của cô ấy và khóa chung của Bob) và Bob tính toán S=d_BH_A (sử dụng khóa riêng của anh ấy và khóa chung của Alice). Lưu ý rằng giống nhau cho cả Alice và Bob, trên thực tế:

S = d_AH_B = d_A(d_BG) = d_B(d_AG) = d_BH_A

Tuy nhiên, Người đàn ông ở giữa chỉ biết H_A và H_B và (cùng với các tham số tên miền khác) và sẽ không thể tìm ra bí mật được chia sẻ S. Nguyên tắc đằng sau vấn đề Diffie-Hellman cũng được Khan Academy giải thích trong một video trên YouTube, sau này giải thích thuật toán Diffie-Hellman áp dụng cho số học mô-đun (không phải cho các đường cong elliptic).

Vấn đề Diffie-Hellman cho các đường anglip được ang một vấn đề “khó”. Nó được cho là “khó” như bài toán logarit rời rạc, mặc dù không có bằng chứng toán học nào khả dụng. Những gì chúng ta có thể nói chắc chắn là nó không thể “khó hơn”, bởi vì giải quyết vấn đề logarit là một cách giải quyết vấn đề Diffie-Hellman.

Bây giờ Alice và Bob đã thu được bí mật chung, họ có thể trao đổi dữ liệu bằng mã hóa đối xứng.

Ví dụ: họ có thể sử dụng tọa độ làm chìa khóa để mã hóa tin nhắn bằng các mật mã bảo mật như AES hoặc 3DES. Đây là ít nhiều những gì TLS làm, sự khác biệt là TLS ghép tọa độ với các số khác liên quan đến kết nối và sau đó tính toán một hàm băm của chuỗi byte kết quả.

Thuật toán chữ ký số dựa trên đường cong Elliptic – ECDHE

“E” trong ECHDE là viết tắt của “Ephemeral” là đề cập đến thực tế là các khóa được trao đổi là tạm thời, thay vì tĩnh. ECDHE được sử dụng, ví dụ, trong TLS, trong đó cả máy khách và máy chủ đều tạo cặp khóa công khai riêng tư khi đang kết nối, khi kết nối được thiết lập. Các khóa sau đó được ký với chứng chỉ TLS (để xác thực) và trao đổi giữa các bên.

Thỏa thuận khóa Diffie-Hellman (DH) là cách để hai bên thỏa thuận về khóa bí mật đối xứng mà không truyền đạt rõ ang khóa bí mật đó. Do đó, nó cung cấp một cách để các bên đàm phán khóa mật mã AES được chia sẻ hoặc bí mật được chia sẻ của HMAC qua một kênh không an toàn. Tuy nhiên, bản thân nó không cung cấp xác thực, do đó, nó dễ bị tấn công giữa chừng mà không có biện pháp bổ sung. Có một số cách để cung cấp các biện pháp bổ sung này (ví dụ: ký các khóa công khai tạm thời bằng chứng chỉ do CA cấp hoặc sử dụng giao thức như OTR), nhưng bài viết này sẽ không thảo luận về chúng ở đây hoặc đi vào chi tiết về cách thức hoạt động của thỏa thuận khóa . Java cung cấp hỗ trợ ngoài luồng cho cả các giao thức thỏa thuận khóa nhật ký rời rạc DH và đường anglip (ECDH) riêng biệt, mặc dù sau này có thể không được hỗ trợ trên tất cả các JRE. ECDH nên được ưu tiên cho bất kỳ ứng dụng mới nào vì nó cung cấp bảo mật được cải thiện đáng kể cho các kích thước khóa hợp lý.

Như thường thấy trong Java, việc sử dụng các lớp này có thể hơi phức tạp. Ở đây chứng minh mã Java đơn giản cho thỏa thuận khóa ECDH trên dòng lệnh. Thỏa thuận khóa ECDHE, trong đó hai bên tạo ra các cặp khóa công khai / khóa riêng duy nhất khi bắt đầu giao thức và bỏ chúng đi sau khi bí mật chung được đàm phán.

Ví dụ mã hoàn chỉnh như sau:

import java.security.*;

import java.security.spec.ECParameterSpec;

import java.security.spec.X509EncodedKeySpec;

import java.security.interfaces.ECPublicKey;

import javax.crypto.KeyAgreement;

import java.util.*;

import java.nio.ByteBuffer;

import java.io.Console;

import static javax.xml.bind.DatatypeConverter.printHexBinary;

import static javax.xml.bind.DatatypeConverter.parseHexBinary;

public class ecdh {

public static void main(String[] args) throws Exception {

Console console = System.console();

// Generate ephemeral ECDH keypair

KeyPairGenerator kpg = KeyPairGenerator.getInstance(“EC”);

kpg.initialize(256);

KeyPair kp = kpg.generateKeyPair();

byte[] ourPk = kp.getPublic().getEncoded();

// Display our public key

console.printf(“Public Key: %s%n”, printHexBinary(ourPk));

// Read other’s public key:

byte[] otherPk = parseHexBinary(console.readLine(“Other PK: “));

KeyFactory kf = KeyFactory.getInstance(“EC”);

X509EncodedKeySpec pkSpec = new X509EncodedKeySpec(otherPk);

PublicKey otherPublicKey = kf.generatePublic(pkSpec);

// Perform key agreement

KeyAgreement ka = KeyAgreement.getInstance(“ECDH”);

ka.init(kp.getPrivate());

ka.doPhase(otherPublicKey, true);

// Read shared secret

byte[] sharedSecret = ka.generateSecret();

console.printf(“Shared secret: %s%n”, printHexBinary(sharedSecret));

// Derive a key from the shared secret and both public keys

MessageDigest hash = MessageDigest.getInstance(“SHA-256”);

hash.update(sharedSecret);

// Simple deterministic ordering

List<ByteBuffer> keys = Arrays.asList(ByteBuffer.wrap(ourPk), ByteBuffer.wrap(otherPk));

Collections.sort(keys);

hash.update(keys.get(0));

hash.update(keys.get(1));

byte[] derivedKey = hash.digest();

console.printf(“Final key: %s%n”, printHexBinary(derivedKey));

}

Để sử dụng ví dụ, biên dịch nó và sau đó chạy hai phiên bản của nó (có thể trên các máy tính khác nhau). Nó sẽ in ra một giá trị khóa công khai được mã hóa hex và sau đó chờ khóa công khai từ thể hiện khác. Chỉ cần sao chép và dán các giá trị từ giá trị này sang giá trị khác (và ngược lại) và sau đó nó sẽ in ra khóa bí mật đã chia sẻ, mã hóa lại hex và cuối cùng là khóa bí mật được chia sẻ.

Bước 1: Tạo cặp khóa ECDHE

Bước đầu tiên là tạo cặp khóa đường anglip ECDHE để sử dụng trong thuật toán, bằng cách sử dụng KeyPairGenerator có tên thích hợp bằng cách sử dụng tên thuật toán ECC để chọn thế hệ khóa Elliptic Curve:

// Generate ephemeral ECDH keypair

KeyPairGenerator kpg = KeyPairGenerator.getInstance(“EC”);

kpg.initialize(256);

KeyPair kp = kpg.generateKeyPair();

byte[] ourPk = kp.getPublic().getEncoded();

Đặt kích thước khóa thành 256 bit, Java sẽ chọn các tham số đường cong NIST P-256 (secp256r1). Đối với các kích thước khóa khác, nó sẽ chọn các đường cong tiêu chuẩn NIST khác, ví dụ: P-384, P-521. Khi muốn sử dụng các tham số khác nhau, phải xác định rõ ang bằng cách sử dụng đối số ECGenParameterSpec.

Bước 2: Trao đổi khóa công khai

Bước tiếp theo là gửi khóa công khai cho bên kia và nhận khóa công khai của họ. Trong trường hợp này, thực hiện bằng cách đơn giản là in chúng ra và yêu cầu một bên thực hiện giao tiếp. Không có xác thực được thực hiện. Điều này có nghĩa là không thể chắc chắn rằng khóa công khai nhận được thực sự là từ bên kia chứ không phải từ một phía trung gian.

// Display our public key

console.printf(“Public Key: %s%n”, printHexBinary(ourPk));

// Read other’s public key:

byte[] otherPk = parseHexBinary(console.readLine(“Other PK: “));

KeyFactory kf = KeyFactory.getInstance(“EC”);

X509EncodedKeySpec pkSpec = new X509EncodedKeySpec(otherPk);

PublicKey otherPublicKey = kf.generatePublic(pkSpec);

Giả định rằng bên kia cũng đang sử dụng khóa chung đường cong NIST P-256. Và đầu ra của PublicKey.getEncoding () là một khóa được mã hóa X.509. Điều này là đúng trong Oracle JRE, nhưng không thể tìm thấy bất kỳ sự đảm bảo nào được ghi nhận về hành vi này.

Bước 3: Thực hiện thỏa thuận chính

Thỏa thuận khóa ECDH thực tế rất đơn giản một khi đã trao đổi khóa chung.

// Perform key agreement

KeyAgreement ka = KeyAgreement.getInstance(“ECDH”);

ka.init(kp.getPrivate());

ka.doPhase(otherPublicKey, true);

Diffie-Hellman hoạt động bằng cách tính toán một bí mật chung dựa trên khóa riêng và khóa công khai, vì vậy đây là tất cả những gì cần trong trường hợp này. DH ở mỗi bên sẽ tính toán cùng một giá trị mặc dù có sẵn các bộ khóa khác nhau.

Bước 4: Trích xuất các khóa bí mật và khóa phái sinh được chia sẻ

Bước cuối cùng là trích xuất bí mật được chia sẻ và sau đó lấy ra một khóa từ nó. Lưu ý rằng không nên sử dụng khóa bí mật được chia sẻ trực tiếp làm khóa đối xứng vì nhiều lý do.

Các thuật toán khóa bất đối xứng được chấp nhận rộng rãi đã thay thế các thuật toán trước, cung cấp bảo mật và hiệu suất tốt hơn để đáp ứng nhu cầu. Mặc dù có nhiều thuật toán đã được phát triển trong nhiều năm qua trong khoa học máy tính, những thuật toán đã nhận được sự hỗ trợ rộng rãi nhất là RSA, DSA và giờ là ECC, có thể được kết hợp với RSA để bảo vệ an toàn hơn nữa.

Để hệ thống mã hóa khóa công khai hoạt động, cần có một bộ thuật toán dễ xử lý theo một hướng, nhưng khó di chuyển theo hướng khác. Tiêu chuẩn đã được sử dụng từ những năm 1970 phụ thuộc vào phép nhân của hai số nguyên tố lớn. Sự khác biệt giữa Diffie-Hellman, RSA, DSA:

Diffie-Hellman:

Thuật toán khóa bảo mật, số nguyên tố đầu tiên được đặt tên là thuật toán Diffie-Hellman và được cấp bằng ang chế vào năm 1977. Thuật toán Diffie-Hellman là giao thức không được xác thực, nhưng yêu cầu chia sẻ khóa bí mật của Bí mật giữa hai bên giao tiếp. Hai bên thống nhất một số bắt đầu tùy ý mà họ chia sẻ, sau đó mỗi bên chọn một số để được giữ riêng tư.

Trong trao đổi quan trọng, mỗi bên nhân số bí mật của họ với số công khai, và sau đó họ trao đổi kết quả. Khi mỗi số nhân các số trao đổi với số riêng của chúng, kết quả sẽ giống hệt nhau, cung cấp nguồn gốc rõ ang giữa các bên. Thật khó, nói một cách tính toán, cho một người nghe bên thứ ba để lấy được các số riêng.

Tuy nhiên, trong trường hợp không có xác thực, Diffie-Hellman dễ bị tấn công giữa chừng, nơi bên thứ ang thể chặn liên lạc, xuất hiện như một người tham gia hợp lệ trong giao tiếp trong khi thay đổi hoặc đánh cắp thông tin.

Rivest Shamir Adeld (RSA):

RSA, được cấp bằng ang chế vào năm 1983 và vẫn là hệ thống được sử dụng rộng rãi nhất cho bảo mật kỹ thuật số, được phát hành cùng năm với Diffie-Hellman, và được đặt theo tên của các nhà phát minh của nó, Ron Rivest, Adi Shamir và Leonard Adeld. RSA nhận được nhiều bảo mật bổ sung bằng cách kết hợp hai thuật toán: một thuật toán được áp dụng cho mật mã bất đối xứng hoặc PKI (Cơ sở hạ tầng khóa công khai) và thuật toán còn lại cung cấp chữ ký số an toàn. Trong khi toán học thiết yếu của cả hai thành phần là tương tự nhau, và các khóa đầu ra có cùng định dạng.

Thuật toán RSA có ba quy trình chính: tạo cặp khóa, mã hóa và giải mã. Các cặp khóa bao gồm việc tạo khóa chung và khóa riêng. Do phần này của quy trình, RSA thường được mô tả là hệ thống bảo mật kỹ thuật số khóa công khai đầu tiên. Khi khóa công khai được tạo, nó được truyền qua kênh không bảo mật, nhưng khóa riêng vẫn được giữ bí mật và không được chia sẻ với bất kỳ ai. Dữ liệu được mã hóa bằng khóa chung, nhưng chỉ có thể được giải mã bằng khóa riêng.

Thuật toán chữ ký số (DSA):

Năm 1991, Cơ quan An ninh Quốc gia (NSA) đã phát triển Thuật toán Chữ ký số (DSA) để thay thế cho thuật toán RSA. Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) đã đưa ra thuật toán này là chương trình mã hóa được chính phủ Hoa Kỳ phê chuẩn và chứng nhận có cùng mức độ bảo mật như RSA, nhưng sử dụng các thuật toán toán học khác nhau để ký và mã hóa.

Giống như RSA, DSA là một sơ đồ mã hóa bất đối xứng, hoặc PKI, tạo ra một cặp khóa, một khóa chung và một khóa riêng. Chữ ký được tạo riêng, mặc dù nó có thể được xác định công khai; lợi ích của việc này là chỉ có một cơ quan có thể tạo chữ ký, nhưng bất kỳ bên nào khác có thể xác thực chữ ký bằng khóa chung. DSA, do đó, ký nhanh hơn, nhưng chậm hơn trong việc xác minh; do đó, DSA là một lựa chọn hợp lý nếu có nhiều vấn đề về hiệu suất hơn ở phía máy khách. DSA và RSA có thể được chạy cùng nhau trong một số hệ thống máy chủ như Apache, cung cấp sự bảo vệ bổ sung.

Tuy nhiên, tương tự nhau, DSA và RSA phải chịu các cuộc tấn công tương tự và RSA đã chuyển sang các khóa dài hơn, điều mà DSA chưa làm được. Mặc dù việc tạo các khóa DSA dài hơn về mặt lý thuyết là có thể, nhưng nó vẫn chưa được thực hiện, do đó, mặc dù có thể so sánh theo các cách khác với RSA, RSA vẫn là sơ đồ mã hóa ưa thích.

III. Ứng dụng

Việc sử dụng mật mã đường cong elliptic (ECC) cho các thiết bị máy tính đã mở rộng trong thập kỷ qua và dự kiến sẽ tiếp tục phát triển. Nhiều ứng dụng sử dụng trao đổi khóa đường cong hình elip lưỡng cực Diffie Hellman (ECDHE) để lấy khóa mã hóa đối xứng như: Bảo mật lớp vận chuyển (TLS) phiên bản 1.3; SIM nhúng và Nền tảng bảo mật thông minh trên mạng; Xác thực ban đầu trong các mạng 5G (w / SUCI).

Mặc dù việc sử dụng trao đổi khóa ECDHE đang phát triển nhanh chóng, nhưng để cải thiện các trao đổi khóa ECDHE giúp ang cường bảo mật hơn nữa và cũng tận dụng các khóa hiện có, được ghi lại bởi các nút tham gia trao đổi khóa ECDHE. Các trao đổi khóa ECDHE được liệt kê ở trên không bao gồm xác thực các nút trong trao đổi khóa ECDHE và các bước riêng biệt sử dụng chữ ký số và chứng chỉ được yêu cầu để xác thực.

Trong Thông tư số 39/2017/TT-BTTTT ngày 15/12/2017 của Bộ trưởng Bộ Thông tin và Truyền thông Công bố Danh mục tiêu chuẩn kỹ thuật về ứng dụng công nghệ thông tin trong cơ quan nhà nước quy định Khuyến nghị áp dụng tiêu chuẩn ECDHE - Elliptic Curve Diifie Hellman Ephemeral và được xếp vào nhóm Tiêu chuẩn về an toàn thông tin.