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

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