Bảo vệ mật khẩu thẻ NFC và khóa vĩnh viễn: Chọn gì trước khi triển khai
Sep 24, 2026
Để lại lời nhắn
Khi thẻ NFC được sử dụng trong quá trình triển khai công khai hoặc{0}}đối mặt với khách hàng, nội dung sẽ không thể chỉnh sửa được một cách ngẫu nhiên. Nhưng "khóa thẻ" có thể có nhiều nghĩa khác nhau và việc chọn sai thẻ có thể tạo ra sự cố không thể khắc phục sau khi sản xuất.
Quyết định thực tế là liệu thẻ có nên duy trì khả năng ghi hay không, yêu cầu mật khẩu cho các hoạt động bộ nhớ được bảo vệ hay trở thành chỉ đọc vĩnh viễn. Câu hỏi thứ tư nằm ngoài lựa chọn đó: nếu dự án cần chứng minh rằng thẻ vật lý là chính hãng thì việc bảo vệ bằng mật khẩu đơn giản hoặc khóa-chỉ đọc là không đủ.
Hướng dẫn này dành cho các nhóm B2B đang chuẩn bị hình dán NFC, nhãn, thẻ, màn hình hoặc các thẻ-có thể đọc được trên điện thoại khác để triển khai hàng loạt. Nó tập trung vào quyết định triển khai, trình tự sản xuất và tiêu chí chấp nhận thay vì các bước lập trình ứng dụng cụ thể.
Bốn yêu cầu khác nhau thường được gọi là "Bảo mật"
| Yêu cầu | Những gì nó thực sự kiểm soát | sử dụng điển hình | Hạn chế chính |
|---|---|---|---|
| Thẻ có thể ghi | Nội dung vẫn có thể thay đổi | Phi công, vận hành, quy trình làm việc nội bộ | Người nào đó có quyền ghi phù hợp có thể thay đổi nội dung |
| bộ nhớ được bảo vệ bằng mật khẩu- | Các hoạt động bộ nhớ đã chọn yêu cầu xác thực được hỗ trợ bởi chip | Cập nhật được kiểm soát khi có thể cần thay đổi trong tương lai | Bảo vệ bằng mật khẩu không giống như mã hóa hoặc bằng chứng xác thực |
| Khóa-chỉ đọc vĩnh viễn | Các trang bộ nhớ đã chọn không thể ghi lại được nữa | Thẻ công khai với tải trọng cuối cùng được phê duyệt | Không thể đảo ngược sau khi các bit khóa liên quan được đặt |
| Xác thực mật mã | Phần phụ trợ hoặc trình đọc xác minh phản hồi bằng mật mã | Các ứng dụng chống-hàng giả và-bảo mật cao hơn | Yêu cầu khả năng chip và kiến trúc hệ thống khác |
Đây không thể thay thế cho nhau. URL bị khóa vĩnh viễn vẫn có thể được sao chép và sao chép trên một thẻ thông thường khác. Mật khẩu có thể hạn chế một số thao tác bộ nhớ mà không mã hóa URL NDEF công khai. Dự án xác thực an toàn có thể vẫn sử dụng URL NDEF, nhưng giá trị bảo mật đến từ giao thức mật mã và xác minh phụ trợ chứ không phải từ thực tế là thẻ ở trạng thái chỉ đọc.
Nếu trước tiên bạn cần kiến thức cơ bản về NFC rộng hơn, Syntek'sHướng dẫn cơ bản về thẻ NFCsở hữu nhiệm vụ giới thiệu đó. Trang này bắt đầu tại thời điểm nội dung thẻ và quy trình triển khai đã tồn tại.

Khóa vĩnh viễn có nghĩa là gì trên các thẻ NTAG21x thông thường
NXP mô tả NTAG213, NTAG215 và NTAG216 là các IC tuân thủ Thẻ loại 2 của Diễn đàn NFC với cả haitrường-có thể lập trình được-chức năng khóa chỉ đọcVàbảo vệ mật khẩu 32-bit có thể cấu hình. Đó là những cơ chế riêng biệt.
trongBảng dữ liệu NTAG213/215/216, byte khóa tĩnh và byte khóa động kiểm soát xem các trang bộ nhớ-người dùng đã xác định có thể được ghi lại hay không. Khi bit khóa liên quan được đặt, vùng được bảo vệ sẽ trở thành-chỉ đọc. Quá trình khóa-bit là một-một cách: không thể đơn giản thay đổi lại bit khóa từ 1 thành 0.
Đó là lý do tại sao khóa vĩnh viễn nằm ở cuối quá trình phê duyệt chứ không phải ở đầu quá trình mã hóa.
cácTài liệu về NFC trên web của Chromesử dụng khái niệm hoạt động tương tự cho các thẻ được hỗ trợ: đặt thẻ-chỉ đọc là thao tác vĩnh viễn, một-một chiều và không thể đảo ngược thông qua quy trình làm việc NDEF thông thường.
Bảo vệ bằng mật khẩu là khả năng kiểm soát có thể đảo ngược, không phải mã hóa
NTAG21x cũng cung cấp khả năng bảo vệ bằng mật khẩu có thể định cấu hình. NXP ghi lại lệnh xác thực-mật khẩu, điểm bắt đầu-khu vực được bảo vệ và cài đặt truy cập có thể hạn chế thao tác ghi hoặc, tùy thuộc vào cấu hình, thao tác đọc và ghi.
Điều đó làm cho việc kiểm soát dựa trên mật khẩu trở nên hữu ích-khi nhà điều hành được ủy quyền có thể cần sửa đổi nội dung được bảo vệ sau này.
Tuy nhiên, mật khẩu thẻ 32-bit không được tiếp thị dưới dạng mã hoá hoặc xác thực bảo mật-cao. Đây là tính năng kiểm soát quyền truy cập-cho các hoạt động bộ nhớ. Nếu thẻ chứa URL công khai mà bất kỳ ai cũng phải đọc thì việc ghi bảo vệ bằng mật khẩu sẽ không làm cho URL đó trở nên bí mật.
Nó cũng tạo ra sự phụ thuộc trong hoạt động: ai đó phải sở hữu mật khẩu, quy trình phát hành, chính sách khôi phục và các công cụ được sử dụng để xác thực và cập nhật thẻ. Việc mất quyền kiểm soát đó có thể biến việc triển khai có thể ghi lại về mặt lý thuyết thành một việc triển khai thực tế không thể bảo trì được.
Sử dụng Vòng đời triển khai để chọn chiến lược khóa
| Điều kiện triển khai | Hướng đề xuất | Lý do |
|---|---|---|
| Nội dung nguyên mẫu hoặc thử nghiệm vẫn đang thay đổi | Giữ có thể ghi | Khóa sớm làm chậm quá trình lặp và có thể lãng phí mẫu |
| Nhân viên nội bộ có thể cần cập nhật bộ nhớ thẻ sau | Cân nhắc việc ghi được bảo vệ bằng mật khẩu-nếu chip đã chọn và quy trình làm việc hỗ trợ tính năng đó | Duy trì khả năng chỉnh sửa được kiểm soát |
| Thẻ công khai chứa URL ổn định cuối cùng | Hãy cân nhắc khóa-chỉ đọc vĩnh viễn sau khi xác thực | Ngăn chặn việc viết lại thông thường tải trọng đã được phê duyệt |
| Nội dung công khai thay đổi nhưng URL có thể ổn định | Khóa URL ổn định và cập nhật đích web | Giữ cố định thẻ vật lý trong khi nội dung thay đổi phía máy chủ |
| Thẻ phải chứng minh mặt hàng thực tế là chính hãng | Sử dụng kiến trúc-có khả năng xác thực | Khóa-chỉ đọc không ngăn chặn việc sao chép nội dung tĩnh |
Việc triển khai công khai dễ bảo trì nhất thường là một URL ổn định, do công ty-kiểm soát được ghi vào thẻ, theo sau là các thay đổi nội dung phía máy chủ-. Trong mô hình đó, bộ nhớ NFC có thể ở trạng thái chỉ đọc-trong khi trang đích, nội dung chiến dịch, thông tin bảo hành hoặc thông tin sản phẩm vẫn có thể chỉnh sửa trực tuyến.
của Syntekhướng dẫn về thẻ NFC trên trang webđề cập đến câu hỏi riêng về việc triển khai NFC dựa trên URL-. Quyết định khóa ở đây bắt đầu sau khi kiến trúc đích đã được phê duyệt.
Không khóa vĩnh viễn một nhà cung cấp-Đích do nhà cung cấp sở hữu nếu không có kế hoạch di chuyển
Khóa vĩnh viễn sẽ đóng băng những gì được lưu trữ trên chip chứ không phải những gì xảy ra trên internet. Sự khác biệt đó chỉ hữu ích nếu tổ chức kiểm soát đích đến hoặc có đường di chuyển đáng tin cậy.
Trước khi khóa thẻ vào URL, hãy xác nhận:
- ai sở hữu tên miền;
- ai kiểm soát chuyển hướng;
- liệu sau này đích đến có thể chuyển sang nền tảng khác hay không;
- URL có chứa đường dẫn cụ thể của nhà cung cấp-có thể biến mất hay không;
- liệu mã thông báo duy nhất trên mỗi{0}}thẻ có còn hiệu lực trong thời gian triển khai dự kiến hay không;
- điều gì sẽ xảy ra khi một chiến dịch, nhân viên, bản ghi sản phẩm hoặc địa điểm bị ngừng hoạt động.
Thẻ vĩnh viễn trỏ đến URL SaaS dùng một lần có thể trở thành lời nhắc nhở vật lý vĩnh viễn về quyết định phần mềm tạm thời. Đối với các thẻ tồn tại lâu dài, việc kiểm soát URL phải được coi là một phần của đặc tả sản phẩm.
Khóa phải tuân theo mã hóa và phê duyệt chức năng
Trình tự sản xuất an toàn tách biệtviết, xác minhVàkhóa.
- Đóng băng quy tắc tải trọng.Xác định chính xác loại bản ghi NDEF, cấu trúc URL, quy tắc mã thông báo-duy nhất và mọi dữ liệu biến đổi.
- Mã hóa thẻ.Viết tải trọng đã được phê duyệt bằng cách sử dụng quy trình sản xuất được chỉ định.
- Đọc lại bằng điện tử.Xác nhận bản ghi được lưu trữ khớp với dữ liệu nguồn.
- Kiểm tra kết quả người dùng.Nhấn vào thẻ đã hoàn thành với điện thoại hoặc đầu đọc mục tiêu đại diện và xác nhận hành động dự định đã hoàn thành.
- Xác minh điểm đến.Kiểm tra chuyển hướng, hành vi HTTPS, quyền sở hữu tài khoản và mọi ánh xạ duy nhất.
- Phê duyệt mẫu tương đương-sản xuất.Mẫu nên sử dụng chip, lớp phủ, vật liệu, tình trạng bề mặt và quy tắc mã hóa cuối cùng.
- Áp dụng trạng thái bảo vệ đã được phê duyệt.Để lại khả năng ghi, định cấu hình kiểm soát mật khẩu hoặc khóa vĩnh viễn theo đặc điểm kỹ thuật của dự án.
- Xác minh trạng thái khóa bài đăng.Đọc lại nội dung và xác nhận hạn chế ghi dự định thực sự có hiệu lực.
- Ghi lại kết quả.Giữ yêu cầu về trạng thái ánh xạ, bản sửa đổi mẫu và khóa{0}}cùng với hồ sơ sản xuất.
Lệnh này ngăn ngừa lỗi thường gặp: chỉ phát hiện ra URL không chính xác, mã thông báo trùng lặp hoặc bản ghi NDEF sai sau khi thẻ đã được đặt ở chế độ chỉ đọc vĩnh viễn.

Đối với các URL duy nhất, tệp ánh xạ cũng quan trọng như trạng thái khóa
Một loạt thẻ NFC có thể chứa một URL chung hoặc mỗi phần có thể mang một mã thông báo khác nhau. Mã hóa duy nhất bổ sung thêm một chế độ lỗi khác: thẻ NFC có thể được khóa chính xác nhưng được ánh xạ tới mục vật lý sai.
Để mã hóa từng phần, bản ghi sản xuất có thể cần các trường như:
| Cánh đồng | Mục đích |
|---|---|
| Trình tự mảnh | Tài liệu tham khảo sản xuất và đóng gói |
| Giá trị nối tiếp hoặc QR được in | Tài liệu tham khảo có thể đọc được-con người hoặc máy ảnh- |
| UID NFC | Mã định danh thẻ điện tử theo yêu cầu của dự án |
| URL hoặc mã thông báo được mã hóa | Đích NDEF thực tế |
| Trạng thái bảo vệ | Chỉ có thể ghi,{0}}được kiểm soát bằng mật khẩu hoặc chỉ đọc vĩnh viễn- |
| Trạng thái xác minh | Vượt qua, làm lại, cách ly hoặc xử lý có kiểm soát khác |
Việc khóa không khắc phục được bản đồ xấu. Trình tự đúng là trước tiên phải xác minh ánh xạ, sau đó áp dụng trạng thái không thể đảo ngược.
Những gì cần kiểm tra sau khi thẻ được đọc vĩnh viễn-Chỉ
Việc kiểm tra cuối cùng phải chứng minh rằng nội dung vẫn hoạt động và trạng thái bảo vệ đã được phê duyệt tồn tại.
| Kiểm tra chấp nhận | Nó chứng tỏ điều gì |
|---|---|
| đọc lại NDEF | Bản ghi được lưu trữ vẫn khớp với tải trọng đã được phê duyệt |
| Hành động của điện thoại hoặc đầu đọc | Thiết bị mục tiêu hoàn thành quy trình làm việc của người dùng dự định |
| Kiểm tra điểm đến | URL phân giải đến trang được phê duyệt hoặc kết quả phụ trợ |
| Ánh xạ dữ liệu-duy nhất | Phần vật lý phân giải thành bản ghi chính xác |
| Viết-kiểm tra hạn chế | Trạng thái bảo vệ được khai báo đang hoạt động |
| Kiểm tra bề mặt | Thẻ vẫn đọc trong điều kiện lắp xong |
| Kiểm tra dự phòng QR | Mọi bản in dự phòng đều đến đích dự định |
Đối với các đơn hàng lớn, hãy xác định xem mọi mục được mã hóa hoặc mẫu được kiểm soát thống kê có được kiểm tra ở mỗi lớp hay không. Kế hoạch lấy mẫu đó là thỏa thuận giữa người mua/nhà sản xuất; nó không nên được thay thế bằng một tuyên bố mơ hồ rằng các thẻ đã được "kiểm tra".
Khóa vĩnh viễn không giải quyết được việc giả mạo vật lý
Không thể ghi lại thẻ NFC{0}}chỉ đọc thông qua các hoạt động bộ nhớ thông thường nhưng thẻ công khai vẫn có thể bị xóa, bị che, thay thế hoặc bị hỏng về mặt vật lý.
Đối với các công trình công cộng, hãy cân nhắc xem dự án có cần:
- giả mạo-kết cấu bằng chứng;
- kiểm tra thực tế định kỳ;
- một dự phòng QR được in;
- sổ đăng ký tài sản/địa điểm được kiểm soát;
- giám sát phụ trợ cho các điểm đến không mong muốn hoặc việc sử dụng mã thông báo;
- quy trình thay thế cho các thẻ bị hỏng hoặc bị thiếu.
Yêu cầu bảo mật vật lý phụ thuộc vào môi trường. Thẻ đánh giá quầy, nhãn tài sản ngoài trời và con dấu xác thực-sản phẩm không có cùng mô hình mối đe dọa.
Bảo vệ bằng mật khẩu không phải là sự thay thế cho xác thực
Sự khác biệt này quan trọng nhất trong các dự án chống hàng giả.
Thẻ tiêu chuẩn có thể bị khóa vĩnh viễn nên bộ nhớ của nó không thể chỉnh sửa được, tuy nhiên dữ liệu hiển thị hoặc đọc được vẫn có thể được sao chép sang thẻ khác. UID cố định có thể hữu ích như một mã định danh, nhưng chỉ dựa vào mã định danh thì không tương đương với bằng chứng mật mã.
Nếu yêu cầu kinh doanh là "ngăn chặn việc ghi lại trái phép", việc kiểm soát ghi dựa trên khóa hoặc{0}}dựa trên mật khẩu có thể phù hợp. Nếu yêu cầu là "chứng minh sản phẩm vật lý này là chính hãng", dự án nên đánh giá một con chip và phần phụ trợ được thiết kế để xác thực.
Kiến trúc bảo mật đó được cố ý nằm ngoài phạm vi của bài viết này. Đừng biến thẻ URL công khai có chi phí-thấp thành sản phẩm "chống{2}}hàng giả" chỉ bằng cách thay đổi trạng thái khóa của thẻ đó.
Xác định trạng thái khóa trong RFQ, không phải sau khi sản xuất
| RFQ / trường phê duyệt | Những gì cần chỉ định |
|---|---|
| Công nghệ chip/thẻ | IC hoặc công nghệ được phê duyệt chính xác trong trường hợp hành vi bảo vệ quan trọng |
| Tải trọng NDEF | URL, văn bản, mã thông báo duy nhất hoặc bản ghi được phê duyệt khác |
| Nguồn dữ liệu | Dữ liệu chung hoặc từng tệp và bản sửa đổi |
| Yêu cầu bảo vệ | Chỉ có thể ghi,{0}}được kiểm soát bằng mật khẩu hoặc chỉ đọc vĩnh viễn- |
| Quyền sở hữu mật khẩu | Ai tạo, lưu trữ và kiểm soát nó nếu sử dụng bảo vệ bằng mật khẩu |
| Khóa thời gian | Sau đó, cổng xác minh có thể bị khóa vĩnh viễn |
| Yêu cầu bản đồ | Mối quan hệ giữa UID, sê-ri in, QR và mã thông báo được mã hóa nếu có |
| Kiểm tra chấp nhận | Kiểm tra hạn chế đọc lại, đích, thiết bị, bề mặt và ghi |
| Xử lý ngoại lệ | Quy tắc làm lại, thay thế hoặc cách ly đối với những phần bị lỗi |
| Thay đổi kiểm soát | Những thay đổi về chip, mã hóa, URL hoặc biện pháp bảo vệ nào cần được phê duyệt lại |
Để tìm nguồn trực tiếp cho các thẻ và nhãn NFC-có thể đọc được trên điện thoại, Syntek'sDanh mục thẻ NFClà chủ thương mại. Nếu dự án yêu cầu-mã hóa và xác minh nội bộ thìDanh mục đầu đọc và ghi NFClà đường dẫn phần cứng có liên quan.
Sắp xếp lại cần khóa-Thay đổi trạng thái-Quy tắc kiểm soát
Thứ tự lặp lại không được kế thừa từ "giống nhau" mà không xác định những gì phải giữ nguyên.
Việc xác nhận lại cần được xem xét khi một thay đổi ảnh hưởng đến:
- mô hình chip hoặc hành vi bộ nhớ/bảo vệ;
- loại bản ghi NDEF hoặc cấu trúc URL;
- mã hóa chung và duy nhất;
- cấu hình mật khẩu hoặc phạm vi bảo vệ;
- chính sách khóa vĩnh viễn;
- bản đồ nối tiếp hoặc QR được in;
- khảm, ăng-ten hoặc vật liệu hoàn thiện;
- bề mặt lắp đặt hoặc bộ điện thoại/đầu đọc dự định.
Thay đổi về mặt thẩm mỹ có thể không yêu cầu kiểm tra lại kỹ thuật hoàn chỉnh, nhưng thay đổi có thể thay đổi hành vi RF, giải thích dữ liệu, ánh xạ hoặc bảo vệ ghi sẽ kích hoạt việc xem xét lớp bị ảnh hưởng.
Quy tắc quyết định
Chọn trạng thái bảo vệ từ mô hình bảo trì, không phải từ từ "an toàn".
Giữ thẻ có thể ghi đượctrong khi việc triển khai vẫn đang được đưa vào vận hành.Sử dụng quyền truy cập được kiểm soát bằng mật khẩukhi các bản cập nhật bộ nhớ được ủy quyền trong tương lai là một yêu cầu vận hành thực sự và chip được chọn hỗ trợ hoạt động cần thiết.Sử dụng khóa chỉ đọc vĩnh viễnkhi tải trọng được mã hóa là cuối cùng và không nên viết lại.Sử dụng xác thực bằng mật mãkhi doanh nghiệp phải xác minh tính xác thực thay vì chỉ ngăn chặn các chỉnh sửa thông thường.
Đối với sản xuất số lượng lớn, trình tự an toàn nhất là:
xác định tải trọng → mã hóa → đọc lại → đích kiểm tra → xác minh ánh xạ → phê duyệt mẫu đã hoàn thành → áp dụng bảo vệ → xác minh bảo vệ → lô phát hành
Trình tự đó giữ cho khóa không thể đảo ngược trở thành lỗi sản xuất không thể khắc phục.
Gửi yêu cầu


