Fobs chính NFC cho hệ thống thành viên: UID, NDEF và ánh xạ thành viên

Một chiếc chìa khóa thông minh NFC có thể nhận dạng một thành viên, mở trải nghiệm web hoặc thực hiện cả hai. Sai lầm là coi đó là quy trình kỹ thuật giống nhau.

Trong chương trình thành viên hoặc chương trình khách hàng thân thiết, câu hỏi quan trọng không chỉ đơn giản là mua chip NFC nào. Đó làhệ thống sẽ tin tưởng mã định danh nào, nơi hồ sơ thành viên sẽ tồn tại và cách thức cấp, thay thế, vô hiệu hóa và gán lại khóa vật lý mà không vi phạm ánh xạ đó.

Hướng dẫn này tập trung vào kiến ​​trúc dữ liệu đó. Nó dành cho các nhà điều hành phòng tập thể dục, câu lạc bộ, nền tảng khách hàng thân thiết, nhà tích hợp-hệ thống thành viên và nhóm mua sắm lên kế hoạch triển khai khóa NFC số lượng lớn.

 

Bắt đầu với giao dịch thành viên, không phải chìa khóa thông minh

Chìa khóa NFC là một thông tin xác thực. Nó không tính điểm, quyết định xem tư cách thành viên có hoạt động hay không, lưu trữ hồ sơ khách hàng có thẩm quyền hoặc tự áp dụng các quy tắc kinh doanh.

Tương tác thành viên thường đi theo một trong hai con đường:

Đường dẫn dành riêng cho người đọc{0}}:
thành viên → Fob khóa NFC → đầu đọc tương thích → mã nhận dạng thông tin xác thực → phần mềm thành viên → hồ sơ thành viên → đăng ký-/lợi ích/quyền

Đường dẫn nhấn vào điện thoại-:
thành viên → fob khóa NFC → điện thoại thông minh → URL NDEF → chương trình phụ trợ web hoặc ứng dụng → bản ghi tài khoản hoặc chiến dịch → hành động thành viên

Những đường dẫn đó có thể sử dụng cùng một hệ số dạng vật lý nhưng chúng không có cùng yêu cầu kỹ thuật.

Nếu dự án chủ yếu là truy cập vào cửa chứ không phải là xác định thành viên thì yêu cầu kiểm soát là hệ thống truy cập được cài đặt. của Syntekhướng dẫn tương thích fob phím lân cậnbao gồm nhiệm vụ người dùng khác nhau đó.

 

UID, NDEF và ID thành viên là ba thứ khác nhau

Các dự án thành viên thường thất bại vì một số mã định danh được coi là có thể hoán đổi cho nhau.

Diễn đàn NFC định nghĩaNDEFlàm định dạng chung cho dữ liệu ứng dụng trên các thiết bị và thẻ tuân thủ Diễn đàn NFC-. Bản ghi NDEF có thể mang URI hoặc tải trọng ứng dụng khác, nhưng ý nghĩa kinh doanh của bản ghi đó thuộc về ứng dụng đằng sau nó.

của NXPTài liệu NTAG213/215/216xác nhận rằng dòng NTAG21x hỗ trợ hành vi Thẻ loại 2 của Diễn đàn NFC, cấu trúc dữ liệu ISO/IEC 14443 Loại A và NDEF. Nó cũng cung cấp UID được lập trình-của nhà sản xuất. Những khả năng đó rất hữu ích nhưng chúng vẫn đại diện cho các lớp khác nhau: UID cho nhận dạng chip, NDEF cho dữ liệu ứng dụng và bản ghi phụ trợ cho logic thành viên.

 

Chọn một trong ba kiến ​​trúc thành viên

1. Đầu đọc chuyên dụng + ánh xạ thông tin xác thực

Trong mô hình này, nhà điều hành cấp từng chìa khóa thông minh làm thông tin xác thực hệ thống. Một đầu đọc tương thích sẽ ghi lại mã định danh hoặc dữ liệu ứng dụng mà nền tảng thành viên mong đợi. Phần phụ trợ ánh xạ thông tin xác thực tới bản ghi thành viên.

Kiến trúc này phù hợp với việc đăng ký định kỳ-, vào câu lạc bộ, tủ khóa,-nhân viên hỗ trợ công nhận mức độ trung thành và các điểm tiếp xúc được quản lý khác nơi người điều hành kiểm soát đầu đọc.

Các câu hỏi quan trọng là:

• Đầu đọc được cài đặt hỗ trợ công nghệ xác thực hoặc chip chính xác nào?
• Phần mềm đăng ký giá trị nào: UID, số thẻ, dữ liệu ngành/tệp hoặc một-giá trị nhận dạng do hệ thống xác định khác?
• Một thành viên có thể có nhiều thông tin xác thực đang hoạt động không?
• Thông tin xác thực có thể bị vô hiệu hóa độc lập với tài khoản thành viên không?
• Thẻ điện tử bị mất, trả lại hoặc thay thế được xử lý như thế nào?

NDEF có thể không liên quan trong kiến ​​trúc này. Chìa khóa thông minh có thể là thông tin xác thực thành viên hợp lệ ngay cả khi không yêu cầu URL có thể đọc được trên điện thoại.

2. Nhấn vào điện thoại + URL NDEF

Trong trải nghiệm làm thành viên lần đầu-trên điện thoại, chìa khóa thông minh thường mang URI NDEF trỏ đến một trang web, quy trình kích hoạt, cổng tài khoản, trang khách hàng thân thiết hoặc lộ trình ứng dụng.

cácTổng quan về kỹ thuật của Diễn đàn NFCmô tả Thẻ diễn đàn NFC là vật mang tin nhắn NDEF có thể kích hoạt các hành động như mở liên kết internet. Apple cũng ghi lại cách đọc thẻ NFC cơ bản xung quanh các bản ghi NDEF URI trên iPhone được hỗ trợ ởNFC lõi.

Đối với kiến ​​trúc này, một URL duy nhất thường phải chứa mã thông báo mờ hoặc số nhận dạng dự án thay vì hiển thị trực tiếp tên, email, số dư hoặc dữ liệu cá nhân không cần thiết khác của thành viên trong thẻ.

Sau đó, phần phụ trợ web có thể phân giải mã thông báo đó thành bản ghi thích hợp và quyết định những gì người dùng được phép xem hoặc làm.

3. Đầu đọc lai + tương tác điện thoại

Một số dự án muốn có một chìa khóa thông minh để hỗ trợ quy trình làm việc của trình đọc được quản lý và trải nghiệm-chạm điện thoại.

Điều đó có thể hữu ích, chẳng hạn như khi phòng tập thể dục muốn có một đầu đọc chuyên dụng để đăng ký-đồng thời cho phép thành viên chạm vào cùng một thiết bị thông minh bằng điện thoại để mở trang tài khoản.

Đừng cho rằng hai đường dẫn này tự động tương thích vì chúng dùng chung chip NFC. Xác thực chúng một cách riêng biệt:

• người đọc phải hỗ trợ công nghệ xác thực và mã định danh chính xác được hệ thống thành viên sử dụng;
• đường dẫn điện thoại phải đọc tải trọng NDEF đã được phê duyệt và mở đích dự kiến;
• chương trình phụ trợ phải biết mối liên hệ giữa-mã nhận dạng phía người đọc và mã thông báo phía NDEF-với cùng một tài khoản;
• người thay thế phải cập nhật cả hai đường dẫn nếu cả hai vẫn hoạt động.

 

 

Quyết định hồ sơ nào là nguồn gốc của sự thật

Thiết kế thành viên an toàn nhất thường giữtài khoản thành viênlà nguồn gốc của sự thật và coi chìa khóa thông minh như một thông tin xác thực có thể chuyển nhượng.

Sự tách biệt đó làm cho việc thay thế và phân công lại dễ dàng hơn.

Điều này cho phép nhà điều hành đình chỉ một thành viên mà không cần viết lại fob về mặt vật lý, thay thế fob khóa bị hỏng mà không cần tạo tài khoản thành viên mới và lưu giữ lịch sử giao dịch khi thông tin xác thực thay đổi.

 

Xây dựng bản đồ trước khi bạn mã hóa hàng loạt

Không bắt đầu tạo dữ liệu biến-với một cột trong bảng tính có tên là "ID". Đầu tiên hãy xác định mối quan hệ giữa các định danh.

Bản đồ sản xuất và triển khai có thể bao gồm:

Để đảm bảo quyền riêng tư và kiểm soát hoạt động, nhà cung cấp thường không cần hồ sơ thành viên đầy đủ. Một mô hình rõ ràng hơn là tách tệp ánh xạ sản xuất khỏi cơ sở dữ liệu thành viên của nhà điều hành.

Ví dụ: nhà cung cấp có thể trả lại:

in nối tiếp ↔ UID ↔ mã thông báo được mã hóa ↔ trạng thái sản xuất

Sau đó, người vận hành có thể thêm:

thông tin xác thực ↔ ID thành viên ↔ trạng thái thành viên

sau khi phát hành.

 

Không sử dụng UID làm lối tắt bảo mật

UID rất hữu ích cho việc nhận dạng, nhưng nhận dạng và xác thực là các chức năng bảo mật khác nhau.

Để tra cứu mức độ trung thành có-rủi ro thấp, việc liên kết mã nhận dạng thông tin xác thực được hỗ trợ với tài khoản phụ trợ có thể là đủ. Đối với-các trường hợp sử dụng có rủi ro cao hơn như truy cập cơ sở an toàn, giá trị được lưu trữ hoặc thanh toán, hệ thống có thể yêu cầu xác thực chip mạnh hơn, dữ liệu ứng dụng được bảo vệ, quản lý khóa và bảo mật-đầu đọc.

Một chiếc chìa khóa thông minh NFC cơ bản không nên được mô tả là an toàn chỉ vì chip của nó có một số sê-ri duy nhất. Mức độ bảo mật được yêu cầu phải đến từ mô hình mối đe dọa và đặc tả nền tảng của chủ sở hữu hệ thống.

Tương tự, vùng bộ nhớ được bảo vệ bằng mật khẩu-không giống như xác thực bằng mật mã.

 

Kế hoạch bị mất-Khóa-Thay thế Fob trước khi ra mắt

Quy trình làm việc thay thế sẽ duy trì tài khoản thành viên trong khi thay đổi thông tin xác thực đang hoạt động.

Một trình tự thực tế là:

1. Tìm tài khoản thành viên.
2. Đánh dấu thông tin xác thực bị mất không hoạt động.
3. Xác nhận xem mã nhận dạng phía trình đọc{0}}cũ có bị chặn sử dụng trong tương lai hay không.
4. Cấp chìa khóa điện tử thay thế.
5. Ánh xạ thông tin xác thực mới vào tài khoản thành viên hiện có.
6. Nếu dự án sử dụng mã thông báo NDEF duy nhất, hãy quyết định xem mã thông báo cũ cũng phải bị vô hiệu hóa hay xoay vòng.
7. Xác minh fob mới tại đầu đọc thực hoặc quy trình làm việc trên điện thoại.
8. Xác nhận rằng thông tin xác thực cũ không còn hoàn thành hành động thành viên được bảo vệ.

Đây là lý do tại sao tài khoản thành viên không được gắn vĩnh viễn với một UID vật lý nếu không có lớp thay thế quản trị.

 

Phân công lại là một hoạt động khác với thay thế

Thay thế giữ nguyên thành viên và thay đổi thông tin xác thực. Việc chỉ định lại giữ thông tin xác thực vật lý và thay đổi thành viên.

Sự khác biệt đó rất quan trọng đối với chìa khóa thông minh có thể tái sử dụng trong phòng tập thể dục, câu lạc bộ, chương trình cho thuê và các cơ sở được quản lý.

Trước khi trả lại fob cho người khác:

• xóa bỏ mối quan hệ thành viên cũ;
• xác nhận tài khoản cũ vẫn không thể sử dụng thông tin xác thực;
• kiểm tra chìa khóa vật lý;
• đọc lại mã định danh điện tử;
• cập nhật hoặc ghi đè nội dung NDEF nếu dự án sử dụng dữ liệu cụ thể của thành viên;
• cân nhắc việc luân chuyển một mã thông báo web duy nhất nếu liên kết cũ có thể đã được sao chép, đánh dấu trang hoặc chia sẻ;
• chỉ định thông tin xác thực cho thành viên mới;
• kiểm tra kết quả đầu đọc cuối cùng và/hoặc điện thoại.

Quy tắc gán lại phải được xác định bởi chủ sở hữu hệ thống. Việc một chiếc chìa khóa thông minh có thể được tái sử dụng về mặt vật lý không chứng tỏ rằng dữ liệu ứng dụng hoặc mối quan hệ tài khoản đã sẵn sàng để sử dụng lại.

 

Tránh lưu trữ dữ liệu thành viên không cần thiết trên Key Fob

Thay đổi dữ liệu thành viên. Tên, trạng thái gói, điểm, lợi ích và chi tiết liên hệ đều có thể thay đổi mà không thay thế thông tin xác thực vật lý.

Vì lý do đó, nhiều dự án sẽ dễ vận hành hơn khi key fob lưu trữ hoặc chỉ hiển thị mã định danh ổn định hoặc mã thông báo URL mờ, trong khi phần phụ trợ lưu trữ dữ liệu kinh doanh đang thay đổi.

Điều này giúp giảm nhu cầu viết lại thông tin xác thực và hạn chế lượng thông tin thành viên bị lộ nếu ai đó quét hoặc đọc thẻ.

Nếu một dự án thực sự cần dữ liệu được bảo vệ trên thông tin xác thực, hãy chọn kiến ​​trúc chip và bảo mật theo yêu cầu hệ thống thay vì bắt đầu với một sản phẩm NTAG chung chung và cố gắng thêm bảo mật sau này.

 

Xác định các quy tắc trùng lặp trước khi đăng ký

Có hai vấn đề trùng lặp khác nhau:

• trùng lặp số nhận dạng điện tử hoặc mã thông báo được mã hóatrong lô sản xuất;
• bài tập đang hoạt động trùng lặptrong cơ sở dữ liệu thành viên.

Kế hoạch chấp nhận sẽ phát hiện cả hai.

Một chiếc chìa khóa thông minh được sản xuất đúng cách vẫn có thể được đăng ký nhầm thành viên. Một thành viên được đăng ký chính xác vẫn có thể có hai thông tin xác thực đang hoạt động khi quy tắc công việc chỉ dành cho một. Đó là những chủ sở hữu lỗi khác nhau và phải được ghi lại riêng biệt.

 

Kiểm tra quy trình làm việc thành viên đã hoàn thành, không chỉ phát hiện NFC

Một thử nghiệm mẫu hữu ích sau giao dịch hoàn chỉnh.

Để có nền tảng rộng hơn về việc kiểm tra dữ liệu, đích đến và ánh xạ NFC trước khi sản xuất hàng loạt, Syntek'sDanh sách kiểm tra kiểm tra NFCgiải thích tại sao một lần nhấn thành công không giống như một quy trình kinh doanh thành công.

 

Những gì cần đặt trong RFQ khóa thành viên NFC

Để tìm nguồn cung ứng trực tiếp thông tin xác thực vật lý, Syntek'sTrang sản phẩm fob khóa NFClà bước tiếp theo về mặt thương mại. Việc lựa chọn sản phẩm phải tuân theo kiến ​​trúc hệ thống đã được phê duyệt thay vì thay thế nó.

 

Quy tắc triển khai

Đối với chương trình thành viên hoặc chương trình khách hàng thân thiết, hãy coi chìa khóa NFC là thông tin xác thực có thể chuyển nhượng chứ không phải là cơ sở dữ liệu thành viên.

Một trình tự triển khai mạnh mẽ là:

nhiệm vụ thành viên → đầu đọc hoặc đường dẫn điện thoại → công nghệ thông tin xác thực → quyết định UID/NDEF → mô hình thành viên phụ trợ → ánh xạ sản xuất → quy tắc phát hành/thay thế/chỉ định lại → đã hoàn thành-kiểm tra mẫu → phê duyệt hàng loạt

Trình tự đó giữ chìa khóa vật lý, mã nhận dạng điện tử, tương tác qua điện thoại và hồ sơ thành viên theo một mô hình dữ liệu được kiểm soát. Nó cũng giúp quản lý việc thay thế fob bị mất và gán lại trong tương lai thay vì biến chúng thành các ngoại lệ cơ sở dữ liệu thủ công.