An Internet of Things intelligent hotel access control system based on NFC technology

Abstract

The present invention specifically relates to an Internet of Things (IoT) intelligent hotel access control system based on NFC technology, comprising a user authentication server, a key distribution server, an APP, and a door lock. The key distribution server is used to provide session key support to the user authentication server, the APP, and the door lock respectively. The user authentication server and the APP mutually transmit data requests and feedback processing results. The user authentication server and the door lock mutually transmit data requests and feedback processing results. The APP transmits an unlocking request to the door lock. Interactions between the APP and any of the user authentication server and the key distribution server are encrypted. Each door lock has a built-in basic key. The present invention has high security, convenience, and popularity.

Description

Technical Field

[0001] The present invention belongs to the field of Internet of Things applications, and in particular relates to an Internet of Things intelligent hotel access control system based on NFC technology. Background Art

[0002] Research on access control systems in my country is still in its infancy, and control methods are relatively traditional compared to those used internationally. In terms of control methods, domestic access control systems primarily include password-based access control systems, radio frequency card access control systems, and biometric access control systems, with radio frequency proximity card access control systems being the most widely used. However, the production of high-security and confidentiality IC cards and related equipment in my country lags behind that of the rest of the world. Currently, most domestic intelligent access control systems are still limited to simple door control, lacking comprehensive, real-time control systems. This simple authentication control system can only meet the needs of ordinary households and low-security venues such as stadiums. For more high-security venues such as laboratories and banks, more secure intelligent access control systems are required.

[0003] Android smartphones are an indispensable communication tool for today's people. With the continuous advancement of communication technology, users demand faster and more reliable data transmission. Near-field communication (NFC) technology, due to its high confidentiality and fast data transmission speed, has found numerous applications in mobile payments, smart keys, and other areas. Given the unique characteristics of NFC, an increasing number of smart mobile terminals are incorporating NFC functionality, and this trend is expected to intensify. Contactless radio frequency identification (RFID) plays a key role in access control systems due to its low cost and ease of use. As a rising star in the short-range contactless communication industry, NFC, successfully developed in 2003, has garnered widespread attention from various industries and has significantly promoted the research and application development of NFC technology.

[0004] However, the existing access control system has many defects in terms of security, convenience and popularity, such as:

[0005] (1) Security: Both password access control and induction access control currently have certain security risks. For example, password access control has the risk of passwords being peeped and passwords being remembered based on gestures, while induction card access control has the risk of card loss and wear.

[0006] (2) Convenience: Currently, the front desk procedures in hotel management are complicated, lacking centralized information management, and consuming a lot of manpower and material resources.

[0007] (3) Popularity: Currently, the prices of high-security access control systems are generally high, making them difficult to be widely promoted in most hotels. Summary of the Invention

[0008] The purpose of the present invention is to provide an Internet of Things intelligent hotel access control system based on NFC technology to solve the problems raised in the above background technology.

[0009] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0010] An IoT smart hotel access control system based on NFC technology includes a user authentication server, a key distribution server, an APP, and a door lock. The key distribution server is used to provide session key support to the user authentication server, the APP, and the door lock respectively. The user authentication server and the APP transmit data requests to each other and feedback processing results. The user authentication server and the door lock transmit data requests to each other and feedback processing results. The APP transmits an unlocking request to the door lock. The interaction between the APP and any server of the user authentication server and the key distribution server is encrypted. Each door lock has a built-in basic key, and a key with the number of unlocking times is stored in the database inside the door lock. The door lock will compare the key value passed in by the user through NFC every time. The comparison range is five times other than the number of door openings. For each door opening request, whether successful or failed, the number of door openings maintained by the service will be increased by one, while the door lock control will not increase the number of failed door openings. When the number of door openings and the door lock base key reach 20 times, the door lock control will actively request the user authentication server to replace the key. When an error occurs in the update, the base key and the number of door openings of the door lock control will not be updated. Since the key replacement operation is an active request by the door lock, not an active replacement by the server, there will be no situation where the door lock cannot be opened due to the key update.

[0011] Furthermore, the key distribution server provides session key support to the APP. Specifically, when the APP is started for the first time, the APP calculates and generates the machine fingerprint, and then calculates and generates its own public key and private key. Then the APP applies for the public key from the key distribution server. After obtaining the public key of the key distribution server, the APP uses the public key of the key distribution server to send a registration request to the key distribution server. After success, the APP public key, private key, and key distribution server public key are saved to the local database. After the key distribution server receives the registration request from the APP, it is saved to the database of the key distribution server.

[0012] Furthermore, the APP calculates and generates a machine fingerprint. Specifically, when generating an identifier, the APP will apply to obtain the CPU serial number and MAC address of the mobile phone, concatenate the two into a string M, and use the SM3 algorithm to calculate and generate a unique identifier. The SM3 algorithm can calculate a message authentication code for a message of any length, and use the final output message authentication code as the unique identifier of the mobile phone. The identifier will not be saved on the hard disk or in the database. The identifier is set to be generated at runtime, and the APP will recalculate the identifier each time the fingerprint is needed.

[0013] Furthermore, the APP calculates and generates its own public key and private key. Specifically, when generating a public-private key pair for use with the RSA algorithm, the java.security.KeyPairGenerator class is responsible for initialization. The initialize() int keysize method of the KeyPairGenerator class is used to generate a key pair with a length of 2048 bits. The key pair generated by the initialization function is stored in an object of the java.security.KeyPair class. The generated public key and private key are obtained through the getPublic() and getPrivate() methods. The generated public key and private key will be stored in a java.util.Map object.

[0014] Furthermore, the APP uses the public key of the key distribution server to send a registration request to the key distribution server. After success, the APP public key, private key, and key distribution server public key are saved to the local database. After the key distribution server receives the APP's registration request, it is saved to the database of the key distribution server. Specifically, after the APP calculates and generates its own public key and private key, the APP will detect whether there is a local database for storing keys. If it does not exist, a new database will be created. If it exists, the public key and private key generated above will be encrypted with a random string K as the key using the AES-256 encryption algorithm and stored in the database. Then, the DH protocol is used to negotiate the session key Ks with the key distribution server. After the session key negotiation is completed, the APP uses the AES-256 encryption algorithm to negotiate the session key Ks with the key distribution server. The key distribution server encrypts the request for "applying for the public key of the key distribution server" using the session key and sends it to the key distribution server. The key distribution server uses the same algorithm and session key to encrypt this message, and then encrypts the public key of the key distribution server and sends it to the APP. After the APP obtains the public key of the key distribution server, the APP uses the public key of the key distribution server to encrypt the APP's public key, the random string K, and the unique identifier of the current mobile phone with RSA, and uses the APP's private key to sign the message and register the current mobile phone with the key distribution server. After the APP completes the registration with the key distribution server, the user can log in, register, and perform other operations. When the user is not logged in, the interactive messages between the APP and the key distribution server will be encrypted with the other party's public key and signed with its own private key.

[0015] Furthermore, the key distribution server is used to provide session key support to the user authentication server. Specifically, the user fills in the registration information on the APP, the APP applies for user registration to the key distribution server, the key distribution server generates a new user, puts it in the cache, and returns the new user's ID to the APP, the APP requests the new user's shared master key from the key distribution server, the APP applies to the key distribution server for the session key with the user authentication server, and the APP registers the user with the user authentication server.

[0016] Furthermore, the user fills in the registration information including user nickname, login password, and door opening password; the APP applies to the key distribution server for user registration, the key distribution server generates a new user, puts it in the cache, and returns the new user's ID to the APP, the APP requests the new user's shared master key from the key distribution server, the APP applies to the key distribution server for the session key with the user authentication server, and the APP registers the user with the user authentication server. Specifically, the APP will use the public key of the key distribution server to encrypt the request for "applying to register a user" and sign it with its own private key and send it to the key distribution server. After receiving this message, the key distribution server generates a new user and stores it in the memory and registers the new user. User initialization generates the new user's ID and the initial shared key with the key distribution server. After initialization is completed, the key distribution server will use the APP's public key to encrypt the new user's ID, sign it with its private key, and then send it to the APP. The APP uses its own private key to decrypt it to obtain the new user's ID. Then, the user ID and the login password entered by the user are combined together and the message digest is generated using SM3 to generate Pl. At the same time, the same operation is performed on the door opening password entered by the user to generate P0. When the generation operation is completed, the APP uses the public key of the key distribution server to encrypt the user ID and the request to "request the shared key between the user and the key distribution server from the key distribution server" and sign it with the APP's private key. After receiving the message, the key distribution server uses the APP public key to encrypt the requested user's shared key and signs it with the key distribution server private key, and sends it to the APP. After the APP receives the message, it decrypts it to obtain the user's shared key and uses this shared key and the AES-256 encryption algorithm to encrypt the request to "apply to the key distribution server for the session key with the user authentication server", and uses the APP's unique identifier and the SHA-256 algorithm to sign it. After the key distribution server receives the request and confirms that it is correct, it generates a new session key and generates a message package consisting of the user ID and session key and encrypts it with the shared key between the user authentication server and the key distribution server. After being linked to the session key, it is encrypted with the user's shared key and the AES-256 algorithm, signed with the private key of the key distribution server and returned to the APP. After the APP decrypts and obtains the shared key, it encrypts the user ID, user nickname, P0, Pl and the message package that the key distribution server requires the APP to forward with the session key and signs it with the session key, and sends it to the user authentication server. After the user authentication server verifies that the information is correct, it saves the user to the user database and informs the key distribution server that the user has completed registration and can store the user in the database. If the key distribution server does not receive the registration completion request from the user authentication server within the agreed time, the key distribution server will release the user.

[0017] Furthermore, every time the APP is restarted and overwritten by other programs, the user needs to log in again. Specifically, the user provides the username and password, the APP requests the user's shared master key from the key distribution server, and then the APP applies for the session key from the key distribution server, and then the APP requests the user to log in from the user authentication server.

[0018] Furthermore, the user authentication server and the door lock transmit data requests to each other and feedback the processing results. Specifically, the management authority of the door purchased by the user is granted to the user. The authority relationship between the user and the door includes administrator authority, general authority, and temporary authority. Temporary authority includes time-based temporary authority and number-based temporary authority. For a NFC-based secure smart hotel access control system door lock, there is only one user with administrator authority, and multiple users with general authority and temporary authority. For each newly generated door, its default administrator authority should be in the management system or in the hands of the manufacturer, but once the door lock is sold, its administrator authority is transferred to the agent. If the user purchases the door, the agent should use his own account to transfer the door lock administrator authority to the user.

[0019] Furthermore, when the user obtains administrator privileges, he or she can add corresponding privileges for family or friends. Specifically, when the user clicks on the door lock privilege management page in the APP, the APP will display the door lock privilege information according to the user's privileges. When the user clicks on the button of the door with administrator privileges, the user will be asked to enter the ID of the user to be added and select a privilege for the user. When the user clicks OK, the APP will send a request for privilege modification to the user authentication server. After receiving the request, the user authentication server will query whether the user has administrator privileges for this door and check the legitimacy of the relevant parameters. After verification, the processing result will be returned. When the user requests to grant administrator privileges, the administrator privileges of the door will be transferred to the new user. When the user requests to grant ordinary privileges, the new user will have the privilege to open the door, but other privileges will not be granted. When the user requests to grant temporary privileges, the new user will have temporary privileges to open the door. The user can also select time-based temporary privileges and number-based temporary privileges for the new user.

[0020] Furthermore, the process of a user opening a door with administrator privileges or general privileges is as follows: when the user walks to the door and clicks the button of the door he wants to open, the APP will ask the user to enter the door opening password. After the user completes the input, the APP initiates a door opening request to the user authentication server. Specifically, the user clicks the door he wants to open and enters the door opening password. The APP sends a door opening request to the authentication server. The authentication server performs authentication based on the message passed in by the APP. When the authentication server determines that the user has the privilege, it queries the database for door lock information. The authentication server calculates the current door opening password based on the queried information. After obtaining the door opening password, the APP reminds the user to bring the mobile phone close to the door lock sensing area. After the door lock senses it, it verifies the correctness of the passed-in password based on its own information. The door lock records the current door opening log and returns it to the authentication server.

[0021] When a user opens a door with temporary permissions, the user authentication server will perform authentication based on the permissions the current user has. For example, if the user has a time-based temporary permission for the door, the user authentication server will verify whether the time when the user's door opening operation is initiated is still within the legal time range. For example, if the user has a number-based temporary permission, when the user initiates the door opening operation, the user authentication server will verify whether the number of times the user has opened the door is still within the legal number. Specifically, the user clicks on the door he wants to open and enters the door opening password. The APP sends a door opening request to the authentication server. The authentication server performs authentication based on the message passed in by the APP. When the authentication server determines that the user has permissions, it queries the database for specific permission information to determine whether the current user's door opening time or number of times the door is opened is within the legal range. The authentication server calculates the current door opening password based on the queried information. After obtaining the door opening password, the APP reminds the user to bring the mobile phone close to the door lock sensing area. After the door lock senses it, it verifies the correctness of the passed-in password based on its own information. The door lock records the current door opening log and returns it to the authentication server. The authentication server updates the user's permissions.

[0022] Beneficial effects

[0023] (1) Security: To address the low security issues of password access control and proximity card access control, the present invention plans to use NFC technology. Users can directly unlock and enter the door by swiping their mobile phone with the key obtained after receiving the instruction. Even if the mobile phone is out of power, the card can be swiped normally. This avoids problems such as passwords being eavesdropped on by others or proximity card being lost. In addition, RSA and AES encryption technologies are used to establish a network security protocol for both parties and perform two-way verification to ensure the legitimacy and security of both parties communicating.

[0024] (2) Convenience: In view of the lack of centralized information management in hotels, the present invention plans to use an intelligent App to conduct unified management and detection of users' check-in information and access control systems, which can simultaneously meet multiple steps and functions such as real-name authentication, information entry, and key distribution, making it convenient for users to check in with one click, greatly simplifying the check-in procedures, saving time and costs for both parties, and further deepening the hotel's information management.

[0025] (3) Popularity: In order to solve the problem of high cost and difficulty in popularization of current access control systems, the present invention has relatively low hardware requirements compared to biometric access control systems. The hardware cost and production cost are much lower than those of biometric access control systems. It also avoids the production of IC cards. In addition, compared with other smart door locks, the service life is also increased, which can effectively solve the problems of high cost and difficulty in popularization. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a system structure diagram of an embodiment of the present invention;

[0027] Figure 2 This is a user usage flow chart of the NFC smart access control system in an embodiment of the present invention;

[0028] Figure 3 This is a flowchart of starting a newly downloaded APP in an embodiment of the present invention;

[0029] Figure 4 A flowchart of user registration in an embodiment of the present invention;

[0030] Figure 5 This is a flowchart of user login in an embodiment of the present invention;

[0031] Figure 6 This is a flow chart of a user obtaining permission to purchase a door in an embodiment of the present invention;

[0032] Figure 7 A flowchart of a user opening an administrator permission or a common permission door in an embodiment of the present invention;

[0033] Figure 8 A flow chart of a user opening a door with temporary permissions in an embodiment of the present invention;

[0034] Figure 9 This is a flow chart of an APP registering with a key distribution server in an embodiment of the present invention;

[0035] Figure 10 A flowchart of user registration in an embodiment of the present invention;

[0036] Figure 11 This is a flowchart of user login in an embodiment of the present invention;

[0037] Figure 12This is a flow chart of a user opening a door in an embodiment of the present invention;

[0038] Figure 13 A flow chart of session key generation in an embodiment of the present invention;

[0039] Figure 14 This is a flow chart of door lock unlocking key generation in an embodiment of the present invention. DETAILED DESCRIPTION

[0040] The following will be combined with the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0041] Based on NFC technology and the Internet of Things, this invention implements smart access control functionality using a Spring Boot-based server, an Android-based client, and a Raspberry Pi-based hardware door lock. RSA or AES encryption technologies are used to protect system security, and two-way authentication is used to verify both the user and the server, ensuring the legitimacy of both communicating parties. The goal is to develop a highly secure smart door lock system that utilizes NFC technology and is tightly integrated with the Internet of Things.

[0042] The present invention mainly includes three modules: authentication server, APP and door lock. The relationship between the three modules is as follows: Figure 1 System structure diagram, including user authentication server, key distribution server, APP and door lock, the key distribution server is used to provide session key support to the user authentication server, APP and door lock respectively, the user authentication server and APP transmit data requests to each other and feedback processing results, the user authentication server and door lock transmit data requests to each other and feedback processing results, the APP transmits unlocking request to the door lock, the interaction between APP and any server of the user authentication server and key distribution server is encrypted, and users of the present invention will experience the following Figure 2 The usage process includes registration, login, permission management, and door opening. Before these steps, each application will go through an initialization process, which is analyzed as follows:

[0043] 1. APP initialization

[0044] When the APP is first started, it will generate an identifier similar to a machine fingerprint to uniquely identify itself, generate its own public key and private key, apply for the public key of the key distribution server, and after obtaining the public key of the key distribution server, encrypt it using the RSA algorithm and sign it using the SHA-1 algorithm. It will register itself with the key distribution server and display the registration result, as shown in the following example: Figure 3 The startup flow chart of the newly downloaded APP. When the APP is started for the first time, the APP calculates and generates the machine fingerprint, and then the APP calculates and generates its own public key and private key. Then the APP applies for the public key from the key distribution server. After obtaining the public key of the key distribution server, the APP uses the public key of the key distribution server to send a registration request to the key distribution server. After success, the APP public key, private key, and key distribution server public key are saved to the local database. After the key distribution server receives the registration request of the APP, it is saved to the database of the key distribution server.

[0045] 2. User Registration

[0046] For every user, registering a user is a necessary step. In this invention, the following information needs to be provided when registering a user: user nickname, login password, door opening password, and the rest of the work is automatically completed by the APP. The specific process Figure 4 As shown in the user registration flow chart, for users registered by this method, the user ID generated in the second step will be displayed to the user in the third step, and the user should use this ID to log in every time thereafter.

[0047] 3. User login

[0048] Every time the APP is restarted, the user must log in again if it is overwritten by other programs. The user should log in using the user ID returned during registration and the password entered during registration. The specific flow chart is as follows Figure 5 The user login flow chart shown.

[0049] 4. User Rights Management

[0050] In the previous section, you've successfully created a user and logged into the app. Now, you need to grant them management rights for the doors they purchased.

[0051] 5. Add a door for the user himself

[0052] The authority relationship between users and doors can be roughly divided into three types: administrator authority, general authority, and temporary authority. Temporary authority is divided into time-based temporary authority and number-based temporary authority. For security reasons, for a secure smart hotel access control system door lock based on NFC, there should be only one user with administrator authority, while general authority and temporary authority should not require the number of users. For each newly generated door, its default administrator authority should be in the management system or in the hands of the manufacturer, but once the door lock is sold, its administrator authority should be transferred to the agent in a timely manner. Once a user purchases the door, the agent should use his own account to transfer the door lock administrator authority to the user, such as Figure 6 The flowchart shown is a process of a user obtaining permission to purchase a door.

[0053] 6. Add a new user to the user's door

[0054] Once the user obtains administrator privileges, he or she can add corresponding permissions for family members or friends.

[0055] When a user taps the door lock permission management page in the app, the app displays the door lock permission information based on the user's permissions. When the user taps the button for a door with administrator permissions, the user is prompted to enter the ID of the user to be added and select a permission for that user. When the user taps OK, the app sends a permission modification request to the user authentication server. Upon receiving the request, the authentication server checks whether the user has administrator permissions for the door and verifies the validity of the relevant parameters. After verification, the result is returned.

[0056] When a user requests administrator privileges, the administrator privileges for the door will be transferred to the new user.

[0057] When the permission requested by the user is a common permission, the new user will have the permission to open the door, but other permissions will not be granted.

[0058] When the permission requested by the user is temporary, the new user will have temporary permission to open the door. The user can also choose to have the right to open the door by time or by number of times for the new user. The right to open the door by time can be used in scenarios such as hotels, while the right to open the door by number of times can be used in scenarios such as cleaning staff who need to open the door when no one is in the room.

[0059] 7. Door opening operation

[0060] The most important thing for an access control system is the door opening operation. In the present invention, each door lock is built-in with a basic key, referred to as the base key, and a key value of the number of unlocking times is stored in the database inside the door lock. The door lock will compare the key value passed in by the user through NFC each time, and the comparison range is five times other than the number of door openings. In theory, for each door opening request (whether successful or failed), the number of door openings maintained by the service will increase once, while the door lock control will not increase the number of failed door openings. When the number of door openings and the door lock base key reaches 20 times, the door lock control will actively request the user authentication server to replace the key. When an error occurs in the update, the base key and the number of door openings of the door lock control will not be updated. Since the key replacement operation is an active request by the door lock, rather than an active replacement by the server, there will be no situation where the door lock cannot be opened due to a key update. The following discusses the situation of users opening the door under different authority levels:

[0061] Open the door with administrator privileges and normal privileges

[0062] The process of users opening doors with administrator privileges or ordinary privileges is the same. When the user walks to the door, the user clicks the button of the door they want to open. The APP will ask the user to enter the door opening password. After the user enters the password, the APP sends a door opening request to the user authentication server. The overall process is as follows Figure 7 Flowchart of a user opening a door with administrator or general permissions. The user clicks on the door they want to open and enters the password. The app sends a door opening request to the authentication server. The authentication server performs authentication based on the message passed by the app. When the authentication server determines that the user has permission, it queries the database for door lock information. The authentication server calculates the current door opening password based on the queried information. After obtaining the door opening password, the app reminds the user to bring the phone close to the door lock sensing area. After the door lock senses it, it verifies the correctness of the password based on its own information. The door lock records the current door opening log and returns it to the authentication server.

[0063] Open the door with temporary permissions

[0064] When a user opens a door with temporary permissions, the server will authenticate the user based on the permissions they currently have. For example, if the user has a time-based temporary permission for the door, the server will verify whether the time the user initiates the door opening operation is still within the legal time range. Similarly, if the user has a number-based temporary permission, the server will verify whether the number of times the user opens the door is still within the legal number of times when the user initiates the door opening operation. Figure 8As shown in the flowchart of a user opening a door with temporary permissions, the user clicks on the door they want to open and enters the door opening password. The APP sends a door opening request to the authentication server. The authentication server performs authentication based on the message passed in by the APP. When the authentication server determines that the user has permission, it queries the database for specific permission information to determine whether the current user's door opening time or number of door openings is within the legal range. The authentication server calculates the current door opening password based on the query information. After the APP obtains the door opening password, it reminds the user to bring the mobile phone close to the door lock sensing area. After the door lock senses it, it verifies the correctness of the passed password based on its own information. The door lock records the current door opening log and returns it to the authentication server. The authentication server updates the user's permissions.

[0065] The advantages of this invention include: addressing the low security issues of password-based access control and proximity card-based access control, the present invention utilizes NFC technology. Users can access the door and check in directly by swiping their phone, using a key obtained after receiving a command. This functionality works even when the phone is out of battery. This prevents passwords from being snooped or proximity cards from being lost. Furthermore, RSA and AES encryption technologies establish a network security protocol and perform two-way authentication between users, ensuring the legitimacy and security of both parties communicating. Addressing the lack of centralized information management in hotels, the present invention utilizes an intelligent app to centrally manage and monitor user check-in information and access control systems. This app can simultaneously handle multiple steps and functions, including real-name authentication, information entry, and key distribution, allowing users to check in with one click, significantly simplifying the check-in process and saving both parties time and money, further deepening the hotel's information management. Addressing the high cost and limited access control system adoption, the present invention offers significantly lower hardware requirements than biometric access control systems, significantly reducing hardware costs and manufacturing costs. Furthermore, the present invention eliminates the need for IC card production and offers a longer lifespan than other smart door locks, effectively addressing the high cost and limited adoption of existing access control systems.

[0066] In a specific embodiment, the present invention provides an IoT smart hotel access control system based on NFC technology. The present invention mainly involves two servers: a key distribution server and a user authentication server. The most important things for the two servers are session security and key generation and transmission.

[0067] 1. Encryption design

[0068] When the APP interacts with any of the two servers, no plain text transmission should be used. In the present invention, multiple encryption algorithms are used, including but not limited to all algorithms involved in the technical solution.

[0069] 1.1. Encryption during APP initialization

[0070] refer to Figure 9The flow chart of the APP registering with the key distribution server is shown. When the APP is first started, the APP will generate an identifier similar to a machine fingerprint to uniquely identify itself.

[0071] In the present invention, when generating an identifier, the app will request the phone's CPU serial number and MAC address, concatenate the two into a string M, and use the SM3 algorithm to calculate and generate a unique identifier. The SM3 algorithm can calculate a message authentication code (32 bytes) for messages of any length. In the present invention, the final message authentication code is used as the unique identifier of this phone, and this identifier is not stored on the hard disk or in a database. The identifier is set to be generated at runtime, that is, the app will recalculate this identifier every time a fingerprint is needed.

[0072] When generating a public and private key pair for use with the RSA algorithm, the java.security.KeyPairGenerator class is responsible for initialization. The initialize int keysize method of the KeyPairGenerator class is used to generate a key pair with a length of 2048 bits. The key pair generated by the initialization function is stored in an object of the java.security.KeyPair class. The generated public and private keys are obtained through the getPublic() and getPrivate() methods. The generated public and private keys will be stored in a java.util.Map object.

[0073] After the app completes the above steps, it checks whether a local database for storing keys exists. If not, it creates a new database. If so, it encrypts the generated public and private keys using the AES-256 algorithm, using a random string K as the key, and stores them in the database. It then uses the DH protocol to negotiate a session key, Ks, with the key distribution server. Once the session key is negotiated, the app encrypts a request for the key distribution server's public key using the AES-256 algorithm and the session key and sends it to the key distribution server. The key distribution server encrypts this message using the same algorithm and session key, then encrypts the key distribution server's public key and sends it to the app. Once the app obtains the key distribution server's public key, it uses the key distribution server's public key to perform RSA encryption on the app's public key, the random string K, and the current phone's unique identifier. The app then signs the message using the app's private key, registering the current phone with the key distribution server. After the APP is registered with the key distribution server, the user can log in, register, and perform other operations. When the user is not logged in, the messages exchanged between the APP and the key distribution server will be encrypted using the other party's public key and signed using its own private key. The specific encryption methods include:

[0074] 1.2. Encryption requirements during user registration

[0075] refer to Figure 10 As shown in the user registration flow chart, in this invention, users are required to enter three values during registration: a user name, a login password, and a door unlock password. Once these values are complete, the user clicks the Register button. The app then encrypts a "user registration" request using the key distribution server's public key, signs it with its own private key, and sends it to the key distribution server. Upon receiving this message, the key distribution server creates a new user, stores it in memory, initializes the new user, and generates an ID for the new user and an initial shared key with the key distribution server. After initialization, the key distribution server encrypts the new user ID using the app's public key, signs it with its private key, and sends it to the app. The app decrypts the new user ID using its own private key. The app then digests the user ID and the user's login password using SM3 to generate P1. The app also performs the same digest on the user's door unlock password to generate P0. Once the generation process is complete, the app encrypts the user ID and a request to the key distribution server for the shared key between the user and the key distribution server using the key distribution server's public key, and signs it with its private key. After receiving the message, the key distribution server encrypts the requested user's shared key using the app's public key, signs it with the key distribution server's private key, and sends it to the app. Upon receiving the message, the app decrypts it to obtain the user's shared key and uses this shared key and the AES-256 encryption algorithm to encrypt a request to the key distribution server for a session key with the user authentication server. The request is then signed using the app's unique identifier and the SHA-256 algorithm. After receiving and confirming the request, the key distribution server generates a new session key and a message packet consisting of the user ID and session key. This is encrypted using the shared key between the user authentication server and the key distribution server. The encrypted result is concatenated with the session key, encrypted using the user's shared key and the AES-256 algorithm, and then signed with the key distribution server's private key and returned to the app. After decrypting and obtaining the shared key, the app then encrypts the user ID, user nickname, P0, P1, and the message packet the key distribution server requested the app to forward using the session key, signs it with the session key, and sends it to the user authentication server. After verifying the information, the user authentication server saves the user to the user database and notifies the key distribution server that the user has been registered and can be stored in the database. If the key distribution server does not receive the registration completion request from the user authentication server within the agreed time, the key distribution server will release the user.

[0076] 1.3. Encryption requirements for user login

[0077] refer to Figure 11 As shown in the user login flow chart, users should log in first when using the present invention, so no matter whether the user opens a new APP or switches from other programs to a running APP, the user should log in first.

[0078] When a user opens the login page, the app asks them to enter their user ID and password. When the user clicks the login button, the app uses the key distribution server's public key to encrypt the user ID and a request to the key distribution server for the user's shared key. The request is then signed with the app's private key. Upon receiving the request, the key distribution server encrypts the user's shared key with the app's public key, signs it with the key distribution server's private key, and sends it to the app. Upon receiving the message, the app decrypts it to obtain the user's shared key. The app then uses the obtained shared key and the AES-256 encryption algorithm to request a session key from the key distribution server for the user authentication server and signs it with the app's private key. After receiving and confirming the request, the key distribution server generates a new session key and a message packet consisting of the user ID and session key. The message is then encrypted using the shared key between the user authentication server and the key distribution server. The encrypted message packet, along with the session key, is then encrypted using the user's shared key and the AES-256 algorithm. The message is then signed with the key distribution server's private key and sent to the app. After decryption, the app obtains the shared key, concatenates the user ID and the login password entered by the user, generates a message digest using the SM3 algorithm, encrypts the user ID, nickname, and the message packet that the key distribution server requested the app to forward using the session key, signs it with the session key, and sends it to the user authentication server. After verifying the information is correct, the user authentication server returns a message confirming successful login.

[0079] 1.4. Encryption requirements when users open the door

[0080] refer to Figure 12 As shown in the user door opening flow chart, in the present invention, the door opening service is the service most frequently used by users. For a certain user, the door is opened and closed at least twice a day. That is, when there are N users in the present invention, the number of door opening services processed per day is at least between N and 2N times.

[0081] When a user needs to use the door unlocking service, they click the app's door unlocking button. The app first encrypts a request for a session key using the shared key between the user and the key distribution server, sending it to the key distribution server. The key distribution server then encrypts the newly generated session key and the message packet mentioned above using the shared key with the user. When the message returns to the app, the app decrypts the session key and uses it to encrypt a request to the user authentication server for the current user's door lock permission list. Upon receiving the request, the user authentication server queries the user's permission list, serializes the list into a String, encrypts the string with AES-256 using the session key, and returns the encrypted result.

[0082] After receiving the encrypted string, the APP decrypts the string, then deserializes the decryption result and displays the result in the form of a door lock list. The user triggers the door opening request by clicking the corresponding specific button in the door lock list.

[0083] After the user taps the button corresponding to the door they wish to open, the app prompts them for a password. After the user completes the entry, the app combines the password and user ID to calculate a digest value. The app then requests a session key from the key distribution server. It then encrypts the user ID and the ID of the door they wish to open, and sends the result to the user authentication server. The user authentication server decrypts the message and authenticates the user. Upon successful authentication, the door base key and the number of door openings are combined using a specific function to calculate the current key. The result is encrypted and returned to the app. After obtaining the key, the app requests a session key for the door from the key distribution server. Once the app obtains the session key for the door lock, it uses it to encrypt the key and sends it to the lock via NFC.

[0084] After the door lock senses the message coming in via NFC, it uses the shared key with the key distribution server to decrypt the message and obtain the session key. It then uses the session key to decrypt the remaining message, thereby obtaining the user ID who wants to open the door and the incoming door opening key. The door lock uses the stored base key and the number of door openings to calculate whether the incoming door opening key is legal, and then applies to the key distribution server for the session key with the user authentication server. After the door lock obtains the session key, it encrypts the door lock ID and user ID and sends them to the user authentication server. The user authentication server queries the user's permissions, records the door opening record, and returns the authentication result to the door lock. If all the above steps are successful, the user successfully opens the door. Specific process Figure 12 .

[0085] 2. Key Generation Design

[0086] In the present invention, the most frequently used service is the session key request, and the most used encryption algorithm is the AES-256 algorithm. The AES-256 algorithm receives a 256-bit key, that is, a 32-byte key (1 byte = 8 bits). Therefore, the present invention requires that the key generation algorithm should meet the following requirements: in a high-concurrency scenario, the passwords of different requests at the same time are different, the keys of the same user at different times are different, and the keys generated by different users within a specific interval are different. For the base key of the door lock, the present invention requires a key with a length of 16 bytes (64 bits). For the shared key between the user, the door lock, the user authentication server, and the key distribution server. The present invention requires a key with a length of 32 bytes (256 bits).

[0087] 2.1. Session Key Generation

[0088] The requirements for session key generation in the present invention are: a length of 32 bytes and high concurrency without conflict.

[0089] The design scheme introduces the ANSI X.9 17 pseudo-random number generator, which is one of the most cryptographically secure pseudo-random number generators currently available. In the present invention, this pseudo-random number generator will be used to generate keys. The output of the ANSI X9.17 pseudo-random number generator is 56 random bits, while the session key length in the present invention is 256 bits. Since the least common multiple of 56 and 256 is 1792 (7 times 256, 32 times 56), in the present invention, a separate thread is opened up in the design of the key distribution center to generate session keys. The key generation factory function runs in this thread, and the factory function continuously stores randomly generated bits in the key cache queue. When a session key request arrives, the key distribution server reads 256 bits from the queue as the session key and returns it to the initiator of the request. The proof of the feasibility of this method is given in Chapter 7 of this article. Specific process Figure 13 The session key generation flow chart shown.

[0090] 2.2. Door lock unlocking key generation

[0091] The door lock's unlocking key is closely related to the door lock's base key and the number of door unlocks. The door lock's base key is a 16-byte (64-bit) key. Figure 14 The door lock opening key generation flow chart shown in FIG. 1 shows a flowchart of a door lock opening key generation flow chart. Each time the door is opened, the door lock base key is calculated using the SM3 algorithm to calculate a digest value. Since the digest length of the SM3 algorithm is 32 bytes (256 bits), which is twice the length of the door lock base key in the present invention, the result of the SM3 algorithm should be compressed twice. The compression algorithm F used in the present invention is as follows:

[0092] ■ Calculate the sum S of the user authentication server CII code for each character of the incoming string M

[0093] ■Determine the parity of S

[0094] If it is an even number:

[0095] Calculate the sum S' of the user authentication server CII code of the character T1 on the odd position in M and its next character T2

[0096] Calculation modulo 2 5 On the other hand, the value of S modulo S' is K

[0097] Take out the Kth character T3 in M

[0098] XOR T1, T2, and T3

[0099] If it is an odd number:

[0100] Calculate the sum of the user authentication server CII code S" of the character T4 and the character symmetrical to T4 in M in the modulo 2 5 On the other hand, the value of S modulo S' is K'

[0101] Take out the K'th character T6 in M

[0102] XOR T4, T5, ~ T6

[0103] ◆The resulting 16-byte (64-bit) string is obtained.

Claims

1. An IoT intelligent hotel access control system based on NFC technology, characterized in that: It includes a user authentication server, a key distribution server, an APP and a door lock. The key distribution server is used to provide session key support to the user authentication server, the APP and the door lock respectively. The user authentication server and the APP transmit data requests to each other and feedback the processing results. The user authentication server and the door lock transmit data requests to each other and feedback the processing results. The APP transmits an unlocking request to the door lock. The interaction between the APP and any server in the user authentication server and the key distribution server is encrypted. Each door lock has a built-in basic key, and a key value of the number of unlocking times is stored in the database inside the door lock. The door lock will record the number of unlocking times for each user. The key value passed in through NFC is compared, and the comparison range is five times other than the number of door openings. For each door opening request, whether successful or failed, the number of door openings maintained by the service will be increased by one, while the door lock control will not increase the number of failed door openings. When the number of door openings and the door lock base key reach 20 times, the door lock control will actively request the user authentication server to replace the key. When an error occurs in the update, the door lock control's base key and the number of door openings will not be updated. Since the key replacement operation is an active request by the door lock, not an active replacement by the server, there will be no situation where the door lock cannot be opened due to the key update; APP will use the public key of the key distribution server to encrypt the request of "applying for user registration" and sign it with its own private key and send it to the key distribution server. After receiving this message, the key distribution server will generate a new user and store it in the memory and initialize the new user, generate the ID of the new user and the initial shared key with the key distribution server. After initialization is completed, the key distribution server will use the public key of APP to encrypt the ID of the new user and sign it with its private key, and then send it to APP. APP will decrypt it with its own private key to obtain the ID of the new user, and then use SM3 to perform message digest on the user ID and the login password entered by the user to generate Pl, and perform the same operation on the door opening password entered by the user to generate P0. When the generation operation is completed, APP uses the public key of the key distribution server to encrypt the user ID and the request of "requesting the shared key between the user and the key distribution server from the key distribution server" and sign it with the private key of APP. After obtaining the message, the key distribution server uses the APP public key to encrypt the shared key of the requesting user and sign it with the private key of the key distribution server, and sends it. The message is sent to the APP. After receiving the message, the APP decrypts it to obtain the user's shared key and uses this shared key and the AES-256 encryption algorithm to encrypt the request to "apply to the key distribution server for a session key with the user authentication server". The request is signed with the APP's unique identifier and the SHA-256 algorithm. After the key distribution server receives the request and confirms that it is correct, it generates a new session key and generates a message packet consisting of the user ID and session key. It uses the shared key between the user authentication server and the key distribution server to encrypt the encrypted result and the session key. After that, it is encrypted with the user's shared key and the AES-256 algorithm, signed with the private key of the key distribution server and returned to the APP. After the APP decrypts and obtains the shared key, it encrypts the user ID, user nickname, P0, Pl, and the message packet that the key distribution server requested the APP to forward with the session key and signs it with the session key. The encrypted result is sent to the user authentication server. After verifying the information, the user authentication server saves the user to the user database and informs the key distribution server that the user has been registered and can be stored in the database.

2. The NFC-based IoT smart hotel access control system according to claim 1, characterized in that: The key distribution server provides session key support to the APP. When the APP is started for the first time, the APP calculates and generates the machine fingerprint, and then calculates and generates its own public key and private key. Then the APP applies for the public key from the key distribution server. After obtaining the public key of the key distribution server, the APP uses the public key of the key distribution server to send a registration request to the key distribution server. If successful, the APP public key, private key, and key distribution server public key are saved to the local database. After the key distribution server receives the registration request from the APP, it is saved to the database of the key distribution server.

3. The NFC-based IoT smart hotel access control system according to claim 2, characterized in that: The APP calculates and generates the machine fingerprint. When generating the identifier, the APP will apply for the CPU serial number and MAC address of the mobile phone, concatenate the two into a string M, and use the SM3 algorithm to calculate and generate a unique identifier. The SM3 algorithm can calculate a message authentication code for messages of any length, and use the final output message authentication code as the unique identifier of the mobile phone. The identifier will not be saved on the hard disk or in the database. The identifier is set to be generated at runtime, and the APP will recalculate this identifier each time the fingerprint is needed.

4. The NFC-based IoT smart hotel access control system according to claim 2, characterized in that: The app calculates and generates its own public and private keys. When generating a public-private key pair for use with the RSA algorithm, the java.security.KeyPairGenerator class is responsible for initialization. The initializeint keysize() method of the KeyPairGenerator class is used to generate a 2048-bit key pair. The key pair generated by the initialization function is stored in an object of the java.security.KeyPair class. The generated public and private keys are retrieved through the getPublic() and getPrivate() methods. The generated public and private keys are stored in a java.util.Map object.

5. The NFC-based IoT smart hotel access control system according to claim 2, characterized in that: The APP uses the public key of the key distribution server to send a registration request to the key distribution server. After success, the APP public key, private key, and key distribution server public key are saved to the local database. After the key distribution server receives the APP's registration request, it is saved to the database of the key distribution server. After the APP calculates and generates its own public key and private key, the APP will detect whether there is a local database for storing keys. If it does not exist, a new database will be created. If it exists, the public key and private key generated above will be encrypted with a random string K as the key using the AES-256 encryption algorithm and stored in the database. Then, the DH protocol is used to negotiate the session key Ks with the key distribution server. After the session key negotiation is completed, the APP uses the AES-256 encryption algorithm and the session key. The APP encrypts the request for "applying for the key distribution server's public key" and sends it to the key distribution server. The key distribution server decrypts this message using the same algorithm and session key, then encrypts the key distribution server's public key and sends it to the APP. After the APP obtains the key distribution server's public key, it uses the key distribution server's public key to perform RSA encryption on the APP's public key, a random string K, and the current phone's unique identifier. It then signs the message with the APP's private key and registers the current phone with the key distribution server. Once the APP has completed registration with the key distribution server, the user can log in and register. If the user is not logged in, all messages exchanged between the APP and the key distribution server will be encrypted with the other party's public key and signed with its own private key.

6. The NFC-based IoT smart hotel access control system according to claim 1, characterized in that: The key distribution server is used to provide session key support to the user authentication server. The user fills in the registration information on the APP, and the APP applies for user registration to the key distribution server. The key distribution server generates a new user, puts it in the cache, and returns the new user's ID to the APP. The APP requests the shared master key of the new user from the key distribution server, and the APP applies to the key distribution server for the session key with the user authentication server. The APP registers the user with the user authentication server.

7. The NFC-based IoT smart hotel access control system according to claim 1, characterized in that: The user authentication server and the door lock transmit data requests to each other and feedback the processing results, granting the user the management authority of the door purchased by the user. The authority relationship between the user and the door includes administrator authority, general authority, and temporary authority. Temporary authority includes time-based temporary authority and number-based temporary authority. For a NFC-based secure smart hotel access control system door lock, there is only one user with administrator authority, and multiple users with general authority and temporary authority. For each newly generated door, its default administrator authority should be in the management system or in the hands of the manufacturer, but once the door lock is sold, its administrator authority is transferred to the agent. If the user purchases the door, the agent uses his own account to transfer the door lock administrator authority to the user.

8. The NFC-based IoT smart hotel access control system according to claim 7, characterized in that: When the user obtains administrator privileges, he or she can add corresponding privileges for family members or friends. When the user clicks on the door lock privilege management page in the APP, the APP will display the door lock privilege information according to the user's privileges. When the user clicks on the button of a door with administrator privileges, the user will be asked to enter the ID of the user to be added and select a privilege for this user. When the user clicks OK, the APP will send a privilege modification request to the user authentication server. After receiving the request, the user authentication server will query whether the user has administrator privileges for this door and check the legitimacy of the relevant parameters. After verification, the processing result will be returned. When the user requests administrator privileges, the administrator privileges of the door will be transferred to the new user. When the user requests ordinary privileges, the new user will have the right to open the door, but other privileges will not be granted. When the user requests temporary privileges, the new user will have temporary access privileges for this door. The user can choose time-based temporary privileges or number-based temporary privileges for the new user.

9. The NFC-based IoT smart hotel access control system according to claim 7, characterized in that: The process for a user to open a door with administrator privileges or general privileges is as follows: when the user walks to the door, the user clicks the button of the door they want to open, the APP will ask the user to enter the door opening password, after the user completes the input, the APP initiates a door opening request to the user authentication server, the user clicks the door they want to open and enters the door opening password, the APP sends a door opening request to the authentication server, the authentication server performs authentication based on the message passed in by the APP, when the authentication server determines that the user has the privilege, it queries the database for door lock information, the authentication server calculates the current door opening password based on the queried information, after the APP obtains the door opening password, it reminds the user to bring the mobile phone close to the door lock sensing area, after the door lock senses it, it verifies the correctness of the passed-in password based on its own information, the door lock records the current door opening log and returns it to the authentication server; When a user opens a door with temporary permissions, the user authentication server will perform authentication based on the permissions the current user has. For example, if the user has a time-based temporary permission for the door, the user authentication server will verify whether the time when the user initiated the door opening operation is still within the legal time range. For example, if the user has a number-based temporary permission, when the user initiated the door opening operation, the user authentication server will verify whether the number of times the user opened the door is still within the legal number. The user clicks on the door he wants to open and enters the door opening password. The APP sends a door opening request to the authentication server. The authentication server performs authentication based on the message passed in by the APP. When the authentication server determines that the user has permissions, it queries the database for specific permission information to determine whether the current user's door opening time or number of times is within the legal range. The authentication server calculates the current door opening password based on the queried information. After obtaining the door opening password, the APP reminds the user to bring the mobile phone close to the door lock sensing area. After the door lock senses it, it verifies the correctness of the passed password based on its own information. The door lock records the current door opening log and returns it to the authentication server. The authentication server updates the user permissions.

Images