Một phương pháp tuyển chọn hệ mã có xác thực hạng nhẹ dùng cho thẻ thông minh - Đinh Tiến Thành

Thông tin khoa học công nghệ Đ. T. Thành, N. Đ. Công, N. N. Chiến, “Một phương pháp tuyển chọn trẻ thông minh.” 220 MỘT PHƯƠNG PHÁP TUYỂN CHỌN HỆ MÃ CÓ XÁC THỰC HẠNG NHẸ DÙNG CHO THẺ THÔNG MINH Đinh Tiến Thành, Nguyễn Đức Công, Nguyễn Như Chiến* Tóm tắt: Trong bài báo này giới thiệu 5 hệ mã có xác thực (ACORN, AEGIS, ASCON, CLOC và MORUS), tham dự cuộc thi CAESAR (tính bí mật, khả năng ứng dụng và tính bền vững của hệ mã mật có xác thực), thực thi cài đặt và đánh giá trên nền tảng Java Card. Trước hết, tiến hành cài đặt từng hệ mã có xác thực sử dụng ngôn ngữ Java trên nền Java Card. Tiếp đó, các hệ mật này được khai thác cùng với các tài nguyên phần cứng của thẻ (bảng mạch trên thẻ): khối đồng xử lý mật mã, bộ nhớ RAM, bộ nhớ EEPROM của Java Card. Tiếp đó đánh giá từng hệ mã có xác thực này theo dung lượng bộ nhớ và hiệu suất thời gian xử lý. Các kết quả này sẽ rất hữu ích trong việc lựa chọn thuật toán mã hóa có xác thực cho các linh kiện nhúng với điều kiện ràng buộc về dung lượng bộ nhớ và điện năng tiêu thụ. Công bố này hỗ trợ lựa chọn hệ mã có xác thực phù hợp với đặc tính của từng kiểu thẻ thông minh. Từ khóa: Hệ thống nhúng; Thẻ thông minh; Hệ mã có xác thực; ACORN; AEGIS; ASCON; CLOC; MORUS; CAESAR. 1. MỞ ĐẦU Trong môi trường công nghệ mạng máy tính hiện nay, bài toán bảo mật thông tin ngày càng trở nên cần thiết và cấp bách. Bảo mật thông tin thường đòi hỏi đảm bảo cả tính bí mật và xác thực. Có 2 cách tiếp cận để thực hiện điều này. Cách thứ nhất là mã hóa thông tin với các thuật toán mã khối hoặc mã dòng để đảm bảo tính bí mật và sử dụng các thuật toán mã xác thực thông báo MAC (Message Authentication Code) để thực hiện xác thực. Ví dụ, có thể dùng mã khối AES ở chế độ CBC để mã thông tin, sau đó dùng thuật toán AES-CMAC (hoặc HMAC) để xác thực. Cách tiếp cận này tương đối dễ, tác động tới tính an toàn vì quá trình mã hóa và xác thực có thể được phân tích gần như riêng biệt. Cách tiếp cận thứ hai là xây dựng các thuật toán mã hóa có xác thực nhằm cung cấp tính bí mật, xác thực và toàn vẹn cho thông báo trong một bước duy nhất (loại bỏ sự không cần thiết của một thuật toán MAC riêng biệt), cách tiếp cận này có lợi về hiệu suất trên các nền tảng tham chiếu khác nhau như FPGA, các hệ nhúng [1]. Cách tiếp cận này đang là hướng đi mới trong khoa học mật mã. Hơn nữa, trước sự phát triển của các hệ nhúng (hệ thống tích hợp cả phần cứng và phần mềm phục vụ các bài toán chuyên dụng trong nhiều lĩnh vực công nghiệp, tự động hoá điều khiển, truyền tin...) thì cũng cần xây dựng các thuật toán mật mã hạng nhẹ có khả năng cài đặt trên các thiết bị giới hạn năng lượng tiêu thụ và khả năng lưu trữ. Đã có nhiều cuộc thi để tuyển chọn các thuật toán mật mã an toàn và hiệu quả, như cuộc thi tuyển chọn chuẩn mã hóa nâng cao AES được công bố năm 1997 với chiến thắng thuộc về thuật toán Rijndael (thuật toán này đã dần thay thế DES và được sử dụng trong nhiều ứng dụng bảo mật như thẻ ngân hàng, bảo mật mạng); tiếp đến là các cuộc thi eSTREAM, SHA-3 và gần đây nhất là cuộc thi CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) nhằm tuyển chọn chuẩn thuật toán mã hóa có xác thực đảm bảo an toàn và hiệu quả khi cài đặt trên các thiết bị giới hạn về tài nguyên. Trong cuộc thi CAESAR, nhiều thuật toán công bố đã được đánh giá trước các tấn công thám mã để xác định sự an toàn của thuật toán. Thông qua các phép đo hiệu suất, diện tích vùng thiết kế, tốc độ và điện năng tiêu thụ của phần cứng thực thi để xác định sức mạnh của từng thuật toán. Phép đo hiệu suất giúp xác định miền ứng dụng của thuật toán. Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 59, 02 - 2019 221 Tài nguyên phần cứng thấp cho phép dùng chip nhỏ hơn, đồng thời miền ứng dụng sẽ rộng hơn, kéo theo đó là điện năng tiêu thụ thấp hơn. Thuật toán tối ưu tốt sẽ đảm bảo được sự an toàn và hiệu quả. Vì những lý do nêu trên mục đích của bài báo này là đưa ra “một phương pháp tuyển chọn hệ mã có xác thực hạng nhẹ dùng cho thẻ thông minh”. 2. NỘI DUNG 2.1. Hệ mã có xác thực (AE – authenticated encryption) hay hệ mã có xác thực dữ liệu liên kết (AEAD – authenticated encryption with associated data) là một dạng của hệ mật khóa đối xứng bảo đảm tính bí mật, tính toàn vẹn, và tính xác thực dữ liệu theo từng bước (Hình 1). Trong đó, phép mã hóa sẽ được kết hợp với khối tạo nhãn (cho phép kiểm tra tính toàn vẹn), còn ở phép giải mã sẽ tiến hành kiểm tra nhãn nhận được. Tính bí mật bảo vệ thông tin bằng cách chuyển đổi bản rõ đầu vào thành các bit ngẫu nhiên độc lập, còn tính xác thực bảo đảm tính toàn vẹn và nguyên gốc của dữ liệu nhờ cơ chế phát hiện sự thay đổi bất kỳ của dữ liệu. Đặc trưng duy nhất chỉ có ở hệ mã có xác thực nằm ở chỗ nó cung cấp đồng thời cả tính bí mật và tính xác thực. Hình 1. Hệ mật mã xác thực. Phần lớn các thuật toán xác thực sử dụng mã dòng hoặc mã khối làm cơ sở để mã hóa dữ liệu, đồng thời ứng dụng cấu trúc bảo toàn trạng thái mã hóa. Hàm cập nhật trạng thái (có phản hồi) được cấp thông số từ một vài đầu vào hoặc toàn bộ đầu vào để tạo nhãn đảm bảo tính xác thực. Nhãn xác thực này cho phép phát hiện các nỗ lực giả mạo. Đây chính là ưu thế của lược đồ kết hợp bảo đảm cả tính bí mật và cả tính toàn vẹn. Tuy nhiên, các tấn công thực tiễn thường tập trung nhiều vào các ứng dụng và giao thức (SSL/TLS), cho thấy hệ mật an toàn cần phải kết hợp cả chế độ bảo mật với chế độ xác thực. Các hệ mật sử dụng khóa bí mật như: • Mã khối: bản tin ngắn có độ dài xác định được mã hóa bằng khóa bí mật, khóa này được chia sẻ giữa người gửi và người nhận. Ví dụ, hệ mật mã khối phổ biến là AES mã hóa từng khối dữ liệu 16-byte (128 bit) bằng khóa bí mật 128-bit, 192-bit hoặc 256-bit. • Mã dòng: bản tin có độ dài biến đổi sẽ được mã hóa nhờ sử dụng khóa bí mật chia sẻ giữa người gửi và người nhận, kèm một giá trị ngẫu nhiên công khai (public nonce). • Mã xác thực thông báo (MAC): bản tin có độ dài thay đổi sẽ được rút gọn qua khối xác thực bằng khóa bí mật chia sẻ giữa người gửi và người nhận, kèm một giá trị ngẫu nhiên công khai (public nonce). Các hàm băm mật mã như SHA-3 và các biến thể của mã khối thường được sử dụng để xây dựng các mã xác thực thông báo – MAC. • Mã hóa có xác thực (AE): bản tin có độ dài thay đổi được mã hóa, cũng như được xác thực bằng cách sử dụng khóa bí mật chia sẻ giữa người gửi và người nhận, kèm theo một giá trị ngẫu nhiên công khai (public nonce). Thông tin khoa học công nghệ Đ. T. Thành, N. Đ. Công, N. N. Chiến, “Một phương pháp tuyển chọn trẻ thông minh.” 222 2.2. Thẻ thông minh Các thẻ thông minh có nhiều tùy chọn phù hợp cho những người làm công tác bảo mật, bởi nó có phần cứng tiết diện vật lý nhỏ, vỏ cách ly độc lập. Thẻ thông minh (Hình 2a) thường chứa một khối vi xử lý, một bộ đồng xử lý, bộ nhớ (RAM và EEPROM) hạn chế, các cổng I/O để giao tiếp với các thiết bị khác. Thẻ thông minh tích hợp bộ đồng xử lý mật mã để mã hóa số liệu, như: AES, RSA, DH,. sức mạnh của hệ mật trong thẻ phụ thuộc vào yếu tố lưu giữ khóa mật và thực thi an toàn các phép toán mã hóa. Thẻ thông minh được ứng dụng rất đa dạng: chip trong thẻ chứa khối vi xử lý với bộ nhớ nhỏ được ứng dụng rộng rãi trong viễn thông như SIM (subscriber identity module) hoặc trong thẻ thanh toán, thẻ tín dụng, thẻ y tế, thẻ xe công cộng (2a) (2b) Hình 2. Thẻ thông minh (Java Card). Các thẻ Java Card có liên hệ mật thiết với các linh kiện nhúng, đặc trưng hiệu suất xử lý thời gian thực và bộ nhớ dung lượng nhỏ. Thẻ thông minh không chứa nguồn nuôi, màn hiển thị, bàn phím. Nó tương tác với thiết bị đầu đọc thẻ qua một giao tiếp truyền thông, gồm 8 tiếp điểm điện từ hoặc quang học (Hình 2b). Các thẻ thông minh bị ràng buộc bởi các linh kiện nhúng có khả năng xử lý và dung lượng bộ nhớ hạn chế. Thách thức đặt ra đối với các thuật toán mã hóa có xác thực ở chỗ cần phải tối ưu hiệu suất xử lý cho thẻ thông minh, bởi cấu trúc lập trình theo ngôn ngữ đặc tả không được thẻ hỗ trợ đầy đủ. 3. THỰC NGHIỆM VÀ KIỂM CHỨNG KẾT QUẢ 3.1. Thực thi cài đặt Chuẩn bị các phép kiểm tra để đảm bảo tính đúng đắn của các thực thi. Dùng các file thông báo có kích thước dữ liệu khác nhau: 256 Bytes, 512 Bytes, 1 KB và 2 KB làm đầu vào cho các thuật toán. Bằng cách so sánh giữa đầu ra từ các thực thi với đầu ra thực thi mà ta cài đặt (kiểm tra ở mức byte). Để đánh giá các hệ mật mã xác thực, nhóm tác giả đã thực thi với đầu đọc USB Reader Gemalto USB [8] trên nền Java Card NXP JCOP CJ2A080 [9]. Để dễ đánh giá, trước tiên thực thi nguyên thủy mã hóa AES [7] ở chế độ CFB (cipher feedback) với khóa 128 bit (10 vòng) làm hệ mật cơ sở để đối chiếu với từng hệ mã có xác thực: ACORN [2], AEGIS [3], ASCON [4], CLOC [5] và MORUS [6]. 3.2. Hiệu suất xử lý Để đo thời gian mã hóa và giải mã các phần dữ liệu. Phép đo này cho phép xác định khả năng xử lý của từng thuật toán trên với các file dữ liệu có kích thước khác nhau. Trên hình 3 biểu diễn thời gian thực hiện mã hóa và giải mã theo từng thuật toán mã hóa/giải mã có xác thực tương ứng. Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 59, 02 - 2019 223 Hình 3. Thời gian xử lý (a) mã hóa và (b) giải mã có xác thực. Dựa trên kết quả thời gian xử lý thấy rằng AEGIS và CLOC là các hệ mật hiệu quả về thời gian, trong số các thuật toán xác thực đã chọn, vì chúng không sử dụng các phép toán dịch bit hoặc tính toán trước phức tạp và chỉ dùng cấu trúc đơn giản để duy trì trạng thái mã hóa. Giữa 2 hệ mật này, AEGIS đạt kết quả về thời gian tốt hơn bởi vì lõi của nó chỉ dùng 5 vòng AES (không cộng XOR với thành phần khóa) thực thi bằng các mảng tìm kiếm. Các giá trị thu được từ các mảng tìm kiếm làm giảm sự tính toán trên Java Card và do đó AEGIS nhanh hơn. Chú ý rằng AEGIS có hiệu suất tính toán lớn hơn so với AES (hệ mật cơ sở) khi xử lý các file dữ liệu lớn hơn; còn với các file dữ liệu nhỏ hơn, AEGIS phải tiền xử lý dữ liệu liên kết (AD), điều này làm nó chậm hơn so với AES. Dẫn đến với các file kích thước dữ liệu lớn, AEGIS sẽ nhanh hơn AES đáng kể (bởi nó chỉ dùng 5 vòng AES). Vì vậy, AEGIS và CLOC sẽ phù hợp hơn cho các thiết bị di động, các thẻ RFID và các thiết bị IoT. Cũng từ Hình 3, thấy MORUS mất khá nhiều thời gian để mã hóa (ví dụ với file dữ liệu 1 KB, nó sẽ mất khoảng 1200 giây, tức là cỡ 20 phút để mã) nên không phù hợp để sử dụng trong thực tiễn. Nguyên nhân làm giảm hiệu suất của thuật toán MORUS chính là do sử dụng quá nhiều các phép toán dịch bit. Các phép dịch bit có giá trị khi thao tác bit (xử lý hướng bit), nhưng nó làm giảm hiệu suất. Mặc dù, có thể tổ chức kết hợp dịch byte, sau đó mới dịch bit nhưng cần nhiều thời gian để tinh chỉnh chi tiết hơn. Song, MORUS có hiệu suất vẫn cao hơn ASCON, bởi ASCON dùng các phép xoay bit mở rộng nên hiệu quả của nó càng giảm mạnh. Hình 3 cho thấy, hiệu quả xử lý theo thời gian của ACORN là kém nhất; bởi vì cấu trúc của nó là hệ mã dòng và phải chuyển đổi từng Byte thành 8 bits, tiếp đến mới thực hiện các phép dịch bit tuyến tính. Khi tất cả các byte đầu vào được xử lý ở mức bit, do đó hệ mã ACORN không phù hợp khi ứng dụng trong Java Card. 3.3. Tài nguyên thực thi Hình 4. Đối chiếu CLOC khi gọi AES mềm và cứng. Thông tin khoa học công nghệ Đ. T. Thành, N. Đ. Công, N. N. Chiến, “Một phương pháp tuyển chọn trẻ thông minh.” 224 CLOC sử dụng hệ mật AES chuẩn mà không có bất kỳ sự thay đổi. Do đó, cho phép đối chiếu hiệu suất khi CLOC dùng AES ở dạng phần mềm và AES được tích hợp trong bộ đồng xử lý mật mã của Java Card. Hình 4 chỉ ra rằng bộ đồng xử lý mật mã (hw-enc) tăng tốc lên cỡ 15 lần so với phép thực thi phần mềm (sw-enc), cùng kích thước file 1 KB thì thời gian xử lý với hw-en mất cỡ 4 giây, còn với sw-enc sẽ mất 60 giây ( 60 15 4  ). Điều này càng thúc đẩy việc xây dựng các thuật toán xác thực kết hợp với xử lý mã mật. * Bộ nhớ chiếm dụng Bộ nhớ của Java Card bị giới hạn và do đó phải tính toán chặt chẽ. Bộ nhớ RAM nhanh hơn 100 lần so với bộ nhớ EEPROM, nhưng dung lượng lại nhỏ hơn EEPROM. Bộ nhớ EEPROM lại bị giới hạn về số chu kỳ ghi cực đại. Các lệnh ghi vào bộ nhớ EEPROM chi phí cao nhưng các lệnh đọc lại nhanh. Do đó, buộc phải cân bằng thực thi hệ mã có xác thực theo các ràng buộc của Java Card để đạt hiệu quả đặt ra và tiết kiệm bộ nhớ. Bảng 1. Dung lượng bộ nhớ bị chiếm dụng theo từng thuật toán. Hệ mật RAM (Byte) EEPROM (Byte) Kích thước hệ mật (Byte) ACORN 845 1690 5760 AEGIS 468 4176 12623 ASCON 476 190 5742 CLOC 832 1247 10149 CLOC (nhờ cứng hóa AES) 832 223 7365 MORUS 192 180 8302 Hình 5. Quan hệ tương đối giữa hiệu suất thời gian xử lý – vùng nhớ bị chiếm dụng của từng thuật toán. Bảng 1 chỉ ra rằng MORUS đạt hiệu quả về bộ nhớ tốt nhất, và do đó có thể gắn vào các linh kiện nhúng có bộ nhớ nhỏ. MORUS dùng bộ nhớ RAM 192 Bytes để lưu các trạng thái mã hóa và các giá trị trung gian. MORUS chỉ chiếm dụng kích thước nhớ EEPROM nhỏ (180 Bytes). ASCON cũng cho thấy hiệu quả về vùng nhớ: 476 Bytes RAM và 190 Bytes EEPROM. CLOC sử dụng AES cứng hóa sẽ tiết kiệm được 1024 Bytes trong bộ nhớ EEPROM so với CLOC thực hiện AES mềm. Vùng nhớ EEPROM thực hiện ACORN là 1690 Bytes, bộ nhớ RAM bị chiếm dụng khá cao 845 Bytes (gồm 293 Bytes bảo toàn các trạng thái mã hóa). AEGIS chiếm hơn 4 KB bộ nhớ EEPROM để lưu các mảng tìm kiếm phục vụ các vòng xử lý của AES. Khi các mảng tìm kiếm này cần đọc (chỉ ghi 1 lần) thì dùng mảng nhớ EEPROM sẽ phù hợp hơn. Do đó, file thuật toán mã Thông tin khoa học công nghệ Tạp chí Nghiên cứu KH&CN quân sự, Số 59, 02 - 2019 225 hóa có xác thực AEGIS cần định dạng Applet để cho phép cài đặt được trong Java Card. Khi xử lý tái dụng một số biến, kích thước file Applet giảm xuống cỡ 12 KB thì sẽ nạp/cài đặt được AEGIS trong Java Card. Hình 5 chỉ ra mối quan hệ tương ứng giữa hiệu suất xử lý và vùng nhớ bị chiếm dụng, giúp chọn lựa thuật toán phù hợp với kiểu thẻ thông minh. Ta thấy: hệ mật AEGIS chiếm dung lượng nhớ EEPROM lớn (Bảng 1), nhưng nó là hệ mật nhanh nhất, giá trị  timeh đạt cực đại; MORUS chiếm dụng bộ nhớ tối thiểu với hiệu suất về thời gian vừa phải; ACORN thể hiện hiệu suất theo thời gian là kém nhất, vùng nhớ RAM bị chiếm dụng lớn nhất trong Java Card; ASCON đạt hiệu quả về bộ nhớ nhưng không đạt hiệu quả về thời gian xử lý; còn CLOC thì không hiệu quả về bộ nhớ nhưng lại đạt hiệu quả cao về thời gian. 4. KẾT LUẬN Các hệ mã có xác thực đáp ứng cả tính bí mật và tính xác thực. Do đó, trong tương lai, các hệ mã có xác thực sẽ là sức kéo chủ đạo nhằm ứng dụng giải pháp mã mật vào các hệ thống tài nguyên hạn chế: các thẻ tín dụng, thẻ cho vay, các SIM, iKey, các phân hệ trong mạng IoT,... Trong bài báo này, chúng tôi đã khảo sát 5 hệ mã có xác thực trên nền tảng Java Card. Đã khai thác các thiết kế và mã nguồn tham chiếu được cung cấp từ các nhà sáng chế ra từng thuật toán trên. Chúng tôi đã xác định các ràng buộc khi giải quyết thách thức cài đặt được hệ mã có xác thực này lên các thẻ thông minh. Hy vọng các kết quả trong bài báo sẽ hữu ích đối với những người làm công tác bảo đảm an toàn cho hệ thống sử dụng thẻ thông minh. Các hướng chủ đạo được nghiên cứu tiếp, bao gồm: • Tối ưu hóa bộ đồng xử lý AES sẵn có trong Java Card: các thẻ thông minh hiện thời có bộ đồng xử lý hỗ trợ AES. Nhóm tác giả đã khai thác CLOC gọi đến khối đồng xử lý AES cứng hóa. Tuy nhiên, các hệ mã có xác thực khác chưa dùng đến AES. Do đó, các điều chỉnh tối ưu hay các tinh chỉnh trong thuật toán để sử dụng bộ đồng xử lý AES sẵn có trên các thẻ thông minh sẽ tăng cường hiệu suất về thời gian xử lý. • Tối ưu hóa các lệnh trong kiến trúc ISA: nay xuất hiện một số kiến trúc xử lý lệnh, như ARM đã cung cấp các lệnh xoay vòng bit trong từng chu kỳ lệnh ISA. Do vậy, khi cải thiện lệnh xoay bit cũng sẽ nâng cao được hiệu quả vùng nhớ và hiệu suất cho các hệ mã có xác thực này. TÀI LIỆU THAM KHẢO [1]. CAESAR: “Competition for Authenticated Encryption: Security, Applicability, and Robustness”. https://competitions.cr.yp.to/caesar-submissions.html. [2]. Hongjun Wu. “ACORN: A Lightweight Authenticated Cipher (v3)”. [3]. Hongjun Wu and Bart Preneel. “AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)”. [4]. Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer. “ASCON v1.2, 2016”. [5]. Tetsu Iwata, Kazuhiko Minematsu, Jian Guo, and Sumio Morioka. “CLOC: Authenticated Encryption for Short Input”. In International Workshop on Fast Software Encryption, pages 149-167, 2014. [6]. Hongjun Wu and Tao Huang. “The Authenticated Cipher MORUS (v2), 2016”. https://competitions.cr.yp.to/round3/morusv2.pdf. Thông tin khoa học công nghệ Đ. T. Thành, N. Đ. Công, N. N. Chiến, “Một phương pháp tuyển chọn trẻ thông minh.” 226 [7]. Andrey Bogdanov, Martin M Lauridsen, and Elmar Tischhauser. “AES-Based Authenticated Encryption Modes in Parallel HighPerformance Software”. IACR Cryptology ePrint Archive. https://eprint.iacr.org/2014/186.pdf. [8].Gemalto. “Java Card & STK Applet Development Guidelines”. [9].Sun Microsystems. “Java Card Applet Developer’s Guide”. 1998. ftp://ftp.icm.edu.pl/packages/javasoft-docs/javacard/JCADG.pdf; ABSTRACT A METHOD OF SELECTING CODE SYSTEM CONFIRMATION FOR THE SMART CARD This paper introduces five authenticated encryption (ACORN, AEGIS, ASCON, CLOC and MORUS), which were attended the CAESAR contest (security, applicability and robustness of the authenticated cipher), implemented and evaluated on the Java Card platform. First, install each authenticated encryption using Java programming language based on Java Card. Then these cryptosystems are exploited with the same card’s hardware resources (circuit board): cryptography co-processing unit, RAM, EEPROM memory of Java card. Evaluate each of these authenticated cryptosystems according to the memory size and processing time. These results are very useful in selecting encryption algorithm for embedded components with constraints on memory capacity and power consumption. This research supports the selection authenticated encryption which is consistent with the characteristics of each type of smart card. Keywords: Embleded system; Smart card; Authenticated encryption; ACORN; AEGIS; ASCON; CLOC; MORUS; CAESAR. Nhận bài ngày 14 tháng 01 năm 2019 Hoàn thiện ngày 17 tháng 01 năm 2019 Chấp nhận đăng ngày 19 tháng 02 năm 2019 Địa chỉ: Học viện Kỹ thuật Mật mã – Ban Cơ yếu Chính phủ. * Email: chienct1102@gmail.com.