Sử dụng Mifare Ultralight C với RC522 trên Arduino: 3 bước

2024 Tác giả: John Day | [email protected]. Sửa đổi lần cuối: 2024-01-30 13:30

Sử dụng công nghệ RFID để xác định chủ sở hữu thẻ hoặc để ủy quyền làm điều gì đó (mở cửa, v.v.) là một cách tiếp cận khá phổ biến. Trong trường hợp ứng dụng DIY, mô-đun RC522 được sử dụng rộng rãi vì nó khá rẻ và có rất nhiều mã cho mô-đun này.

Trong hầu hết các trường hợp, UID của thẻ được sử dụng để "xác định" chủ thẻ và thẻ Mifare Classic được sử dụng vì chúng rẻ và thường được bao gồm khi mua mô-đun RC522.

Nhưng như bạn có thể biết, hệ thống Mifare Classic đã bị tấn công trong một số năm và nó không còn được coi là an toàn nữa. Hệ thống mã hóa Crypto1 được sử dụng bởi thẻ Classic có thể được khắc phục và đây là những thẻ có thể ghi lại, nơi dữ liệu mà một UID có thể được lập trình lại (thẻ ma thuật).

Vì vậy, đối với bất kỳ ứng dụng liên quan đến bảo mật nào, việc sử dụng thẻ Mifare Classic không được khuyến khích! Điều tương tự cũng áp dụng cho (hầu hết) hệ thống NTAG và Mifare Ultralight

Vì vậy, lựa chọn là sử dụng một hệ thống chuyên nghiệp hoặc cố gắng sử dụng một hệ thống RFID an toàn hơn. Các hệ thống có sẵn là Mifare Ultralight C, Mifare DESFire và Mifare Plus. Vì có nhiều hệ thống chuyên nghiệp sử dụng các hệ thống an toàn hơn này, nên đối với cộng đồng DIY hầu như không có giải pháp nào (có một giải pháp DESFire dựa trên Teensy, dựa trên bảng đột phá PN523 đắt tiền hơn). Ngoài ra, thẻ DESFire khá đắt. Vì vậy, thách thức là tìm ra một giải pháp tốt hơn và rẻ hơn.

Giải pháp được trình bày cung cấp toàn quyền truy cập vào thẻ Mifare Ultralight “C” giá rẻ bằng cách sử dụng mô-đun RC522 DIY giá rẻ của Trung Quốc. Dựa trên mã này, Mifare Ultralight C an toàn có thể được sử dụng trong các ứng dụng DIY.

Bước 1: Điều kiện tiên quyết

Mặc dù RC522 được thiết kế tốt, nhưng trong hầu hết các trường hợp, nó được xây dựng kém vì một số thành phần có kích thước kém. Điều này dẫn đến danh tiếng xấu của mô-đun là nó có độ nhạy thấp và không phải tất cả các loại thẻ sẽ được xác định. Đặc biệt là Mifare Ultralight C sẽ không nhận dạng được cũng như không đọc được thẻ.

Vấn đề chính là đặc điểm kỹ thuật của cuộn cảm L1 và L2. Như được mô tả trên https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Chỉ bằng cách thay thế những cuộn cảm này thành những cuộn cảm thích hợp, ví dụ: FERROCORE CW1008-2200 đột nhiên RC522 cho thấy tiềm năng thực sự của nó là gì.

Vì vậy, trước khi thử mã đã cho, bạn PHẢI THAY THẾ các cuộn cảm. Nó chỉ sẽ không hoạt động với các cuộn cảm được cài đặt sẵn!

Nền tảng của tất cả những điều này là các thẻ Ultralight C khá ngốn năng lượng. Năng lượng này được cung cấp bởi trường RF RC522. Do cường độ dòng điện của cuộn cảm thấp, trường năng lượng không đủ mạnh để cung cấp năng lượng cho Ultralight C. Các thẻ khác như Mifare Classic chỉ cần ít năng lượng hơn và do đó hoạt động khá ổn định.

Bước 2: Nó hoạt động như thế nào?

Vậy sau khi sửa đổi mô-đun RC522, bạn có thể sử dụng Mifare Ulralight C cho ứng dụng của mình như thế nào?

Bí quyết là Mifare Ultralight C hỗ trợ xác thực mật khẩu dựa trên mật mã 3DES. Bằng cách sử dụng mật khẩu này, nội dung của thẻ có thể được đặt ở chế độ “chỉ đọc” hoặc hoàn toàn ẩn đối với người dùng trái phép.

Để sử dụng mật khẩu bảo vệ này, mật khẩu cần được ghi vào thẻ và các trang cần được bảo vệ. Sau khi hoàn tất, bạn có thể xác minh thẻ trong ứng dụng của mình bằng cách chỉ yêu cầu xác thực dựa trên mật khẩu hoặc dữ liệu sẵn sàng bổ sung từ khu vực được bảo vệ. Chỉ khi điều này thành công, bạn mới biết rằng bạn có thể tin tưởng vào UID được cung cấp trên thẻ.

Hãy lưu ý: nếu không có xác thực dựa trên mật khẩu, bạn vẫn không thể tin tưởng thẻ Mifare Ultralight C, vì có những “thẻ ma thuật” cũng mô phỏng Ultralight C.

Mỗi thẻ độc lập với công nghệ (nếu ở tần số chính xác) sẽ phản hồi với UID của chúng khi được cung cấp bởi trường RF và yêu cầu nhận dạng chính chúng. Ngoài ra, chúng cung cấp giá trị SAK cung cấp thông tin tối thiểu về loại thẻ hiện có. Thật không may, tất cả Mifare Ultralight và NTAG đều xác định là loại syme (SAK = 0x00), bao gồm cả Mifare Ultralight C. Vì vậy, khi kiểm tra thẻ, ít nhất giá trị SAK là 0x00 sẽ gợi ý rằng có thể có Ultralight C trên đầu đọc.

Để đảm bảo đó là Ultralight C, bạn có thể gửi yêu cầu xác thực được mã hóa đến thẻ. Nếu đây KHÔNG phải là thẻ Ultralight C, yêu cầu này sẽ không được hiểu và phản hồi sẽ là NAK (not-acknolege).

Nếu đây là thẻ Ulralight C, bạn sẽ nhận được câu trả lời 8 byte. 8 Byte này là một số ngẫu nhiên “B” (RndB) được mã hóa bởi khóa lưu trữ trên thẻ bằng cách sử dụng mật mã 3DES.

RndB được mã hóa này phải được giải mã bằng cùng một khóa trong chương trình. Số ngẫu nhiên này sau đó được sửa đổi một chút (xoay một byte → byte 1 sẽ được chuyển xuống byte 8 và tất cả các byte khác được đẩy xuống một byte, khi đó được gọi là RndB’). Sau đó, chương trình tạo ra một số ngẫu nhiên 8 Byte “A” chính nó (RndA) và gắn RndA này vào RndB’đã được sửa đổi. Điều này một lần nữa được mã hóa bằng cách sử dụng khóa và gửi đến thẻ.

Thẻ giải mã thông điệp và kiểm tra xem RndB’có phù hợp với RndB được tạo trước đó trên thẻ hay không. Nếu chúng khớp nhau, thẻ bây giờ biết, chương trình biết khóa.

Tại thời điểm này, chương trình vẫn chưa biết liệu thẻ có biết khóa hay không và do đó có thể tin cậy được hay không. Để đạt được điều này, bây giờ thẻ sẽ xoay RndA đã giải mã theo một byte, sau đó mã hóa các byte này bằng khóa và gửi chúng trở lại.

Sau đó, chương trình sẽ giải mã câu trả lời của thẻ và kiểm tra xem RndA gốc và RndA đã trả lời có khớp nhau hay không. CHỈ SAU ĐÓ cả hai thực thể (chương trình và thẻ) biết rằng chúng chia sẻ kiến thức về cùng một khóa.

Quá trình này chỉ được sử dụng để xác thực. Tất cả các thông tin liên lạc tiếp theo luôn ở dạng "văn bản rõ ràng".

Mặc dù có các thẻ “Ultralight C ma thuật” mà UID có thể được sửa đổi, bản thân khóa không thể lấy được từ thẻ và mật mã 3DES khá an toàn. Chìa khóa là khóa 16 Byte, do đó, cách tiếp cận thô bạo để lấy được khóa sẽ mất một khoảng thời gian.

Như đã nêu, thông tin liên lạc trước khi xác thực và sau khi xác thực luôn ở dạng văn bản rõ ràng (hay còn gọi là không được mã hóa). Khi ghi một khóa mới vào thẻ, nội dung của khóa có thể được phát hiện bằng cách sử dụng thiết bị phù hợp. Vì vậy, vui lòng ghi khóa chỉ trong môi trường an toàn và giữ bí mật khóa.

Khi sử dụng thẻ Ultralight C

Thẻ Ultralight C tích hợp nhiều tính năng bảo mật:

1. Bộ nhớ lập trình một lần (OTP). Trong khu vực này, các bit có thể được ghi, không bị xóa bus.
2. Bộ đếm một chiều 16 bit. Bộ đếm này chỉ có thể tăng lên khi có giá trị.
3. Bảo vệ “ghi” hoặc “đọc / ghi” các trang trong bộ nhớ. Chỉ khi được xác thực bằng khóa, các trang này mới có thể được đọc hoặc sửa đổi.
4. Đóng băng / chặn các trang riêng lẻ để bảo vệ khỏi bất kỳ sửa đổi nào.

Việc sử dụng OTP, bộ đếm 16 bit hay sử dụng bit chặn đều không được triển khai trong mã đã cho, nhưng có thể dễ dàng triển khai dựa trên thông tin được cung cấp trong https://www.nxp.com/docs/en/data- sheet / MF0ICU2.pd…

Vì việc bảo vệ bằng phím là điều cần thiết khi sử dụng Mifare Ultralight C nên tất cả các chức năng liên quan đều có mặt.

Tất cả các lệnh được sử dụng trong màn hình nối tiếp với "chỉ dòng mới" và với 115200 Baud

• “Auth 49454D4B41455242214E4143554F5946” sẽ yêu cầu xác thực với khóa đã cho (trong trường hợp này là khóa Mifare Ultralight C tiêu chuẩn)
• "Dump" sẽ kết xuất nội dung của thẻ theo cách chúng có thể nhìn thấy được. Trong trường hợp các trang được bảo vệ bằng khóa, các trang này có thể không hiển thị cho đến khi xác thực trước đó bằng khóa. Trong hai cột đầu tiên, nó được chỉ ra nếu các trang bị khóa hoặc quyền truy cập bị hạn chế.
• “NewKey 49454D4B41455242214E4143554F5946” sẽ ghi một khóa mới vào thẻ. Khóa được ghi vào các trang từ 44 đến 47. Điều này sẽ chỉ hoạt động nếu các trang này không bị khóa hoặc được bảo vệ mà không có xác thực trước đó.
• "wchar 10 hello world" sẽ viết "hello world" bắt đầu từ trang 10. Một lần nữa, điều này chỉ hoạt động của các trang không bị khóa hoặc được bảo vệ mà không có xác thực trước đó. Khi cố gắng viết ở trên trang 39 hoặc bên dưới trang 4, điều này sẽ nhắc lỗi hoặc dữ liệu bị bỏ qua vì các trang này không phải là bộ nhớ của người dùng.
• “Whex 045ACBF44688” sẽ ghi các giá trị Hex trực tiếp vào bộ nhớ, các điều kiện trước đó được áp dụng.
• "Protect 30" bảo vệ tất cả các trang từ trang 30 trở lên. Tùy thuộc vào sự cho phép, các trang này sau đó chỉ có thể được sửa đổi hoặc đọc sau khi xác thực trước bằng khóa. Sử dụng "bảo vệ" với các giá trị cao hơn 47 sẽ đặt tất cả các trang thành "không được bảo vệ" BAO GỒM PHÍM ở các trang 44-47 (chỉ có thể sửa đổi nhưng không đọc được). Để ngăn việc thay đổi khóa, biện pháp bảo vệ ít nhất phải bắt đầu từ trang 44.
• “Setpbit 0” đặt bit bảo vệ và quyết định xem các trang được bảo vệ chỉ được đọc (“setpbit 1”) hay không được đọc không được ghi (“setpbit 0”) mà không có xác thực trước đó bằng khóa.

Không phải tất cả các lệnh đều có thể được sử dụng ngay sau khi thẻ được phát hiện. Một "kết xuất" trước đó cho một lệnh khác luôn luôn hữu ích.

Bước 3: Quan trọng

1. Chương trình phân biệt giữa các loại Siêu nhẹ bằng cách đọc trang 43 và 44. Nếu trang 43 có thể đọc được và trang 44 không, rất có thể đó là Siêu nhẹ C. NHƯNG, nếu bạn đọc / ghi, bảo vệ trang 43, thẻ sẽ không được nhận dạng nữa. Ultralight C (không ảnh hưởng đến bất cứ thứ gì) Việc xác định đúng Ultralight phải được thực hiện thông qua xác thực bằng khóa (tôi đã không thực hiện điều đó vì lý do ổn định).
2. Trước khi sử dụng lệnh “setpbit” và “bảo vệ”, lệnh “kết xuất” phải được sử dụng, nếu không trạng thái bảo vệ của các trang sẽ không được biết.
3. Nếu bạn “đọc / ghi” bảo vệ các trang đầu tiên của thẻ, chương trình này sẽ không hoạt động nữa với chương trình này vì trang đầu tiên được đọc liên tục để xem còn thẻ hay không. Vì hai trang đầu tiên chỉ được đọc (UID được lưu trữ ở đó), nên không có ý nghĩa gì trong việc bảo vệ chúng.

Các vấn đề về độ ổn định

Mã này sử dụng thư viện RC522 "tiêu chuẩn" cho Arduino và thư viện 3DES từ https://github.com/Octoate/ArduinoDES. Trong khi thư viện RC522 được sử dụng khá phổ biến, thư viện 3DES dường như không phổ biến và phải được cài đặt thủ công.

Mã đã được thử nghiệm trên Arduino Uno. Nhưng trong khi viết nó, tôi gặp phải nhiều vấn đề kỳ lạ liên quan đến sự ổn định. Bằng cách nào đó hoặc kỹ năng lập trình của tôi không tốt lắm, một trong những thư viện đã sử dụng không ổn định hoặc trộn các thư viện không phải là một ý kiến hay.

Hãy ghi nhớ điều này khi sử dụng mã !!!

Thay đổi hoặc chỉ sử dụng các phần của thẻ có thể dẫn đến các hành vi kỳ lạ như bị rơi, in những thứ kỳ lạ hoặc hết thời gian chờ hoặc NAK khi đọc từ thẻ. Điều này có thể xảy ra ở bất kỳ vị trí nào trong mã (tôi mất nhiều giờ gỡ lỗi). Nếu bạn tìm thấy (các) lý do cho điều này, vui lòng cho tôi một gợi ý.