ĐÔI NÉT VỀ HỆ MÃ CÓ XÁC THỰC VÀ THẺ THÔNG MINH

Hệ mã có xác thực

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ật 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. 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 nhận biết 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à 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 được chia thành các khối có độ dài xác định và đượ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).

Hình 1. Hệ mật mã xác thực

• 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. 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.

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 hoặc trong thẻ thanh toán, thẻ tín dụng, thẻ y tế, thẻ xe công cộng…

 

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 đủ.

THỰC NGHIỆM VÀ KIỂM CHỨNG KẾT QUẢ

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 được cài đặt (kiểm tra o 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].

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.

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. 

Hình 3. Thời gian xử lý (a) mã hóa và (b) giải mã có xác thực

Cũng từ Hình 3 cho 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 vẫn 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, thì hệ mã ACORN không phù hợp khi ứng dụng trong Java Card.

Tài nguyên thực thi

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 tính đồng xử lý mật mã (hw-enc) tăng tốc lên cỡ 15 lần so với phần 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-enc mất cỡ 4 giây, còn với sw-enc sẽ mất 60 giây. Sự so sánh 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.

Hình 4. Đối chiếu CLOC khi gọi AES mềm và cứng

Bộ nhớ chiếm dụng

Bộ nhớ của Java Card bị giới hạn nên cần được 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 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

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ã 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.

Hình 5. Quan hệ tương đối giữa hiệu xuất thời gian xử lý vùng nhớ bị chiếm dụng của từng thuật toán

Hình 5 cho 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ị 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 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.

KẾT LUẬN

Bài báo đã trình bày kết quả thực thi 5 hệ mã có xác thực trên nền tảng Java Card dựa trên khai thác các thiết kế và mã nguồn tham chiếu của từng thuật toán trên. Trong nội dung bài viết cũng đã 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. 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,...

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:ALightweightAuthenticated Cipher (v3)”. http://competitions.cr.yp.to/round3/acornv3.pdf. 3. Hongjun Wu and Bart Preneel. “AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)”. http://competitions.cr.yp.to/round3/aegisv11.pdf. 4. Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer. “ASCON v1.2, 2016”. http://competitions.cr.yp.to/asconv12.pdf. 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. 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”. http://developer.gemalto.com. 9. Sun Microsystems. “Java Card Applet Developer’s Guide”. 1998. ftp://ftp.icm.edu.pl/packages/javasoft- docs/javacard/JCADG.pdf.