1. Constraints in Design
?? The u2f Protocol can only be supported on websites that support HTTPS. This is not a problem for commercial sites. However, for LAN or internal development environments, we use a self-signed certificate for HTTPS.
?? When a u2f device is signed and registered on a webpage, it will check the request's "appid". The "appid" must be a domain name or machine name and cannot be an IP address, otherwise, an error occurs.
2. demo2.1. how to obtain code for a website that supports u2f
The https://github.com/solarkai/FIDO_U2F_KEDACOM provides a site project that supports u2f. Although it is only a site demo, it provides a complete function for managing users and u2f devices.
2.2. How to build and run
?? The client of this project is written using jquery and jquery-ui, and the server is written using the spring-boot framework. You can use Maven to build the SDK by running the following command:
./mvnw clean package
?? For the generated jar package, run the following command (jdk1.8 is recommended) directly (note that the tomcat. keystore file must exist in the current working directory; otherwise, a spring injection error will be reported ):
java -jar Kedacom-U2F-DEMO-0.0.1-SNAPSHOT.jar
?? After the preceding program runs, a Tomcat server is started, which supports both HTTP and HTTPS modes. You can use the "http: // localhost: 8080" and "https: // localhost: 8443" modes in the browser to access the service. In the http mode, the u2f device is not supported.
2.3 How to support https
?? To Use https, you need to use a self-signed certificate. We use the built-in JDK keytool to generate the self-signed certificate tomcat. keystore, which is placed in the current working directory during project running. The command is as follows:
keytool -genkeypair -keystore tomcat.keystore -alias tomcat -keyalg RSA -keysize 2048 -validity 5000 -dname "CN=localhost, OU=kedacom, O=kedacom, L=shanghai, ST=shanghai, C=cn" -ext "SAN=DNS:localhost,IP:172.16.64.59" -ext "BC=ca:true"
?? To prevent the browser from generating alarms for self-signed certificates. export the Public Key Certificate (CER file) in the keystore to import the "Trusted Root Certificate Authority" of the browser. The command to export the Public Key Certificate is as follows:
keytool -keystore tomcat.keystore -export -alias tomcat -file tomcat.cer
?? In the application. properties file of the project, the related HTTPS parameters are defined. These parameters are injected into the variable by spring at the project startup. The application. properties is defined as follows:
#httpshttps.port=8443https.ssl.key-store=tomcat.keystorehttps.ssl.key-store-password=tomcathttps.ssl.keyAlias=tomcat#u2fu2f.appId=https://localhost:8443
?? If you use the code of this project to build your own site, be sure to ensure that the application. in the properties file, "u2f. appid ", tomcat. in the keystore, CN and San are consistent with the domain name (machine name.
2.4. How to achieve user data persistence
?? The disk persistence of user data is not implemented in this project, which means that after the server is restarted, all user data previously saved will be lost. However, persistence is also very simple for interested readers. The project uses com to operate user data. kedacom. u2f. users. iuserstore implementation. The implementation object of this interface is injected when the system starts. Currently, Com. is used in the project code. kedacom. u2f. users. usersstoreinmemory object injection. You only need to replace usersstoreinmemory injection with the custom persistence object that implements iuserstore.
2.5. Site Functions
?? The demo of this project site provides complete user and u2f device management functions, user addition, deletion, modification, u2f device registration, binding, authentication, and other functions.
2.5.1 user management
?? The admin user is generated by default when the site is started. You can use the initial user name and password of "admin/admin" to log on. Figure 1 shows how to add, delete, and modify passwords.
2.5.2. Bind and unbind u2f Devices
?? A user on this site can bind (Register) Multiple u2f devices, and cannot bind the same u2f device twice. The same u2f device can be bound by multiple users.
?? Figure 2 shows a user's device binding process. When the site is bound, a user is prompted to touch the device.
?? Figure 3 shows the data after the device is bound.
?? Figure 4 shows the registration data of a user bound to multiple devices. The data bound to each device is identified by keyhandle.
?? You can select one of the keyhandle to unbind. The u2f device corresponding to the keyhandle does not function during logon authentication, as shown in Figure 5.
2.5.3. User logon authentication
?? For a user bound to a u2f device, you must not only verify the user name and password, but also verify the u2f device, as shown in figure 6.
2.6. Third-party libraries used
?? The u2f signature and registration Interface scripts used by the project on the client are from the https://demo.yubico.com/js/u2f-api.js, where the server uses the u2flib-server-core and u2flib-server-attestation libraries provided by yubico, and the following dependencies can be added to the POM file:
<dependency> <groupId>com.yubico</groupId> <artifactId>u2flib-server-core</artifactId> <version>0.19.0</version> </dependency> <dependency> <groupId>com.yubico</groupId> <artifactId>u2flib-server-attestation</artifactId> <version>0.19.0</version> </dependency>
?? The two libraries provide functions such as certificate verification, Public Key extraction, and signature verification in u2f device registration information. The core class is com. yubico. u2f. the u2f class references Java. security-related packages and classes, the code value is one read.
3. References
- Https://fidoalliance.org/how-fido-works/
- Https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/FIDO-U2F-COMPLETE-v1.2-ps-20170411.pdf
- Http://www.ietf.org/rfc/rfc4648.txt
Fido u2f Application and Development (III)-develop websites supporting u2f