Use EMQX Cloud to implement one-machine, one-password authentication for IoT devices

Data security is a top priority for IoT applications. Manufacturers often use symmetric encryption, asymmetric encryption, digital signature, digital certificate and other methods to authenticate devices to prevent access of illegal devices. In terms of the use of certificates, there are different schemes such as one type, one key, one machine, one key, etc. Among them, the one machine one key scheme pre-sets a unique device certificate for each device, and can perform two-way verification when the device communicates with the server. , after the verification is passed, the device side and the server side perform normal data transmission. Compared with other solutions, one machine, one password can achieve individual authentication and authorization for each device, and has higher security.

As a secure and reliable fully managed MQTT message cloud service, EMQX Cloud supports multiple authentication methods, including basic authentication (username/password, client ID/password) and JWT, PSK and X.509 certificate authentication, and external databases can be configured at the same time Validate authentication information as a data source.

This article will use Redis as the authentication data source to store the database, and explain how to use the Common Name contained in the device-side certificate as the verification information to connect to EMQX Cloud to achieve one-machine, one-key authentication on the client side. If the client certificate does not have the specified unique Common Name, it cannot pass the authentication.

Through this article, readers can realize one machine, one password, two-way identity authentication between the device and the server, and the ability to establish a secure channel for their IoT devices, effectively preventing forged device attacks, cracked device keys, forged server instructions, and monitoring or tampering with key information. , Stealing keys and other attack methods through equipment production line security vulnerabilities.

Operating procedures

1. Configure TLS/SSL mutual authentication

1. Preparation

1. Purchase a server certificate and resolve its domain name to the deployment connection address.

   

2. Generate a client root ca self-signed certificate, and use the self-signed root ca certificate to issue a client certificate to ensure that the Common Name is unique.

    # CA 证书生成 client-ca.crt，subj 依据实际使用情况调整。
   openssl req \
       -new \
       -newkey rsa:2048 \
       -days 365 \
       -nodes \
       -x509 \
       -subj "/C=Common Name/O=EMQ Technologies Co., Ltd/Common Name=EMQ CA" \
       -keyout client-ca.key \
       -out client-ca.crt
   
   # 客户端秘钥生成 client.key
   openssl genrsa -out client.key 2048
   
   # 生成客户端证书请求文件 client.csr，Common Name 为客户端携带认证信息
   openssl req -new -key client.key -out client.csr -subj "/Common Name=346a004d-1dab-4016-bb38-03cca7094415"
   
   # 用 CA 证书给客户端证书签名，生成 client.crt
   openssl x509 -req -days 365 -sha256 -in client.csr -CA client-ca.crt -CAkey client-ca.key -CAcreateserial -out client.crt
   
   # 查看客户端端证书信息
   openssl x509 -noout -text -in client.crt
   
   # 验证证书
   openssl verify -CAfile client-ca.crt client.crt

2. Configuration process

Log in to the EMQX Cloud console . Enter the deployment details, click the +TLS/SSL configuration button to configure the certificate content, you can upload a file or directly fill in the certificate content TLS/SSL authentication type:

① One-way authentication: Only the client verifies the server certificate.

② Two-way authentication: The client and the server mutually verify the certificate.

In this example document, we take two-way authentication as an example, and fill in the following content in the deployment console:

① Public key certificate: server certificate

② Certificate chain: certificate chain, usually provided when a third-party organization issues a certificate

③ Private key: private key

④ Client CA certificate: When two-way authentication is selected, the client's CA certificate needs to be provided

After filling in, click OK until the status is running, that is, the TLS/SSL mutual authentication configuration is complete.

2. Configure Redis authentication/access control

This article takes Redis authentication/access control as an example. Of course, you can also use other external authentication data sources. In the scenario described in this article, Redis authentication/access control is recommended.

1. Create a VPC peering connection

On the EMQX Cloud deployment details page, create a VPC peering connection so that the intranet of the professional version can be accessed to your Redis authentication database.

2. Configure Redis authentication/access control

1. redis configuration

   In your cloud server, create a Redis service. For the convenience of demonstration, we use Docker to quickly build here.

    docker run -itd --name redis -p 6379:6379 redis:latest

   There are two ways to configure the data in this example (choose one of two):

    HMSET  tls_domain:346a004d-1dab-4016-bb38-03cca7094415 password pubic
   HMSET  tls_subject:346a004d-1dab-4016-bb38-03cca7094415 password pubic

   

2. Redis authentication/access control configuration

   During identity authentication, EMQX Cloud will use the current client information to fill in and execute the authentication query command configured by the user to query the authentication data of the client in Redis.

   The following placeholders can be used in the authentication SQL and EMQX Cloud will automatically populate the client information when executed:

   • %u: username
   • %c: Client ID
   • %C: TLS certificate common name (the certificate's domain name or subdomain name), valid only for TLS connections
   • %d: TLS certificate subject, valid only for TLS connections

   You can adjust the authentication query command according to your business needs and use any command supported by Redis(opens new window), but in any case, the authentication query command must meet the following conditions:

   ① The first data in the query result must be password, EMQX uses this field to compare with the client password

   ② If the salting configuration is enabled, the second data in the query result must be the salt field, which is used by EMQX as the salt (salt) value

   In the deployment, click Authentication - External Authentication and Authorization - Redis Authentication/Access Control, and click Configure Authentication to create a new authentication.

   The authentication query command has the following two methods:

    HMGET tls_domain:%C password
   HMGET tls_subject:%d password

   That is, the device needs to carry the client certificate, client secret key, and its Common Name and password for authentication.

   

Test verification

We use the MQTT X simulation client to connect to EMQX Cloud with the following information.

① Server CA

② The client certificate and client key whose Common Name is 346a004d-1dab-4016-bb38-03cca7094415

③ password: public

Click connect in the upper right corner, and connected appears to indicate that the connection is successful. So far, the device with the specified common name has been successfully connected to EMQX Cloud, that is, the one-machine-one-secret device has been authenticated and connected to EMQX Cloud successfully.

Epilogue

So far, we have completed EMQX Cloud's client-side, one-machine, one-certificate verification process and successfully connected to the deployment. Compared with other solutions, one machine, one password can achieve individual authentication and authorization for each device, with higher security. If you also set a unique access credential for each of your IoT devices, you can refer to Configure this article.

Copyright statement: This article is original by EMQ, please indicate the source when reprinting.

Original link: https://www.emqx.com/zh/blog/one-device-one-secret-authentication-for-iot-devices-with-emqx-cloud