Certificate from the server

Abstract

A method and suitably configured apparatus are provided for gaining trust in a server in a network by a client, the network comprising the server. The method includes, by the client, obtaining a certificate of a bootstrap server and checking whether a root certificate of a certificate chain to which the certificate belongs, or the certificate itself if it is a self-signed certificate, is in a store of trusted certificates. If the root certificate, or the certificate itself if it is a self-signed certificate, is not in the trusted store, checking whether the bootstrap server is local to the network and, if the server is local to the network, adding the root certificate or the certificate itself if it is a self-signed certificate to the store.

Description

[Technical Field]

[0001] The present invention relates to an apparatus and method for use in wireless networks, particularly wireless networks conforming to the IEEE 802.11 family of standards. [Background technology]

[0002] When implementing TLS (Transport Layer Security [RFC 8446]) and SSL (Secure Sockets Layer [RFC 6101]), one of the available security options is server-side authentication using certificates. This means that when a client device contacts a server over a network, it obtains, among other information, a certificate from the server. The certificate contains a public key from the server and other information, such as the server's Internet Protocol (IP) address, a Uniform Resource Locator (URL) where the server can be found, and / or the name of the server or server company. All of this information is digitally signed with a private signing key.

[0003] If this private signing key belongs to the public key in the certificate, the certificate is so-called self-signed, in which case the client can use the server's public key in the certificate to check the signature on the certificate.

[0004] If the private signing key belongs to another party, then the public signing key belonging to the private signing key is also listed in the certificate and belongs to the signed data. In this case, the client can use the public signing key in the certificate to check the signature on the certificate. In this case, the server uses a Public Key Infrastructure (PKI).

[0005] An important issue for the client is whether the signing key in the certificate can be trusted. If the client trusts the signing key, it checks the signature on the certificate. If the signature is correct, it can inspect the other information in the certificate to see if it is also correct. For example, if the certificate contains an IP address or URL, the server is to be contacted via this IP address or URL; if not, the server that sent this certificate cannot be trusted. If the certificate contains a company name, the client (or its user) can check if this company name is indeed the name of the company the user wants to contact.

[0006] In a PKI, this problem for clients is solved in the following way: Certain companies act as so-called certificate authorities (CAs). CAs have self-signed certificates. CA self-signed certificates are called root certificates. Operating system (OS) vendors and Internet browser vendors collect the root certificates they trust and store them in a secure location on the device, so that root certificates cannot be added or removed without restrictions. A superuser must explicitly grant this permission. If an attacker can insert their own root certificate into a browser, the browser will trust all certificates that lead to this root certificate. This allows an attacker to trick the browser into trusting, for example, a pirated banking site. OS vendors and browser vendors also store the certificates of the vendor CAs. The certificates of intermediate CAs are signed by the CA or another intermediate CA.

[0007] So, if the first certificate is not self-signed, the client will search its certificate store for a second certificate that contains a public signing key. This second certificate is also checked. If it is correct, and this second certificate is also from an intermediate CA, the client will then search further for a third certificate that contains a second public signing key, and so on, until the certificate found is a root certificate. All certificates from the server's to the root form a certificate chain.

[0008] It is desirable to provide efficient certificate handling, especially in network settings. Summary of the Invention [Problem to be solved by the invention]

[0009] It is desirable for the wireless network configuration to function in a manner that allows TLS to be used for the resulting connection between the server and the device using the service. [Means for solving the problem]

[0010] There is therefore provided a method of gaining trust in a server in a network by a client, the network comprising the server, the method comprising the steps of: obtaining, by the client, the server's certificate; and checking whether a root certificate of a certificate chain to which said certificate belongs, or said certificate itself (if it is a self-signed certificate), is in a store of trusted certificates. If the root certificate, or the certificate itself if it is a self-signed certificate, is not in the trusted store, the method comprises checking whether the server is local to the network, and if a bootstrap server is local to the network, adding the root certificate or the certificate itself if it is a self-signed certificate to the store.

[0011] If the server is local, it may not have access to a certificate authority. However, being local is under the user's control and can therefore be given a degree of trust. By verifying that the server is local, the client can trust the server and therefore store the certificate even in the absence of third-party authentication. By storing the certificate in a store of trusted certificates, the client can recognize the server in the future.

[0012] According to one aspect of the invention, the server is a bootstrap server and the client is a bootstrap configurator.

[0013] In this situation, the method can be advantageously used in the commissioning / configuration of devices in a network using a local server for bootstrap, the bootstrap being performed on a bootstrap server.

[0014] In one aspect, the method performs an ownership check of the certificate to verify whether the certificate belongs to the local server, and if the certificate belongs to the local server, continues execution of the method; otherwise, aborts execution of the method.

[0015] If the client finds that the server is not local, it is useful to terminate the method at that point, as trust cannot be established. If the server is local, the server is considered trusted.

[0016] In one aspect of the invention, the local server has no connection to a certificate authority.

[0017] Even in these circumstances, the method allows for the building of trust.

[0018] In one aspect of the invention, the client performs a signature check on the certificate, and if the certificate is not self-signed, the client performs a signature check on all certificates in the certificate chain to which the certificate belongs, and if the check indicates that at least one of the signatures is incorrect, the client aborts execution of the method.

[0019] Unless all signatures on the available certificates are correct, the client cannot be sure that even the local server can be trusted.

[0020] In an aspect of the present invention, the certificate is obtained in an out-of-band (OOB) manner.

[0021] The use of OOB methods adds a level of security by allowing the transfer of information that is itself sensitive (i.e., should remain private to legitimately participating devices) to be exchanged before trust is established and encryption is set up.

[0022] In one aspect of the present invention, the OOB method includes a QR code or NFC.

[0023] One aspect of the present invention configures an enrollee for communication in a wireless network.

[0024] In one aspect of the present invention, the enrollee is bootstrapped by obtaining the enrollee bootstrap information in an OOB manner.

[0025] In one aspect of the present invention, a protocol conforming to the Wi-Fi Device Provisioning Protocol is executed.

[0026] There is also provided a configurator device according to the above method, running a local server and further configured to configure the device for communication in a wireless network.

[0027] Further provided is a bootstrap configurator device according to the above method, configured to obtain OOB bootstrap enrollee information and communicate the enrollee bootstrap information to a bootstrap service.

[0028] There is also provided a computer program product configured to perform the above-described method when executed on a computer processor. [Brief explanation of the drawings]

[0029] The above and additional objects, features, and advantages of the disclosed apparatus, systems, and methods will be better understood through the following illustrative and non-limiting detailed description of embodiments of the apparatus and methods, taken in conjunction with the accompanying drawings. [Figure 1] 1 is a diagram illustrating a wireless network to which a device may be configured for addition. [Figure 2] FIG. 4 is a diagram showing the flow of a setting process according to the embodiment. [Figure 3] 10 is a flow chart illustrating a part of a setting process according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0030] In the following description, like reference numerals refer to like elements.

[0031] FIG. 1 illustrates a local wireless network 1 including a first device 2 and another device 3, which may be a (network) printer. The first device 2 has central functions and may be something like an access point (AP), hub, or gateway device. The first device 2 is referred to below as an AP for simplicity, although other types of devices are indeed possible. A user (not shown) wants to add two more devices to the local wireless network 1: a complex device 4 (represented here as a computer) and a simple device 5 (represented here as a toothbrush). Devices like the simple device 5 often have no actual user interface (UI) other than perhaps a light and are therefore often referred to as "headless" devices. The first device or AP 2 has a processor 6, while the simple device 5 has a microcontroller and small non-volatile memory 7, as well as a button 8 that can be used to reset the simple device 5. There is also a third device 9, which may be a configurator. Finally, there is a bootstrap configurator 10. The server can reside in any of these devices, specifically the first device or AP 2, device 3, or device 9. The servers can provide any service: in particular, AP 2 and device 9 can provide, for example, a bootstrap service, and device 3 can provide something like a printing service.

[0032] Some wireless network standards allow one device (the configurator or commissioner) to configure another device (the enrollee) to establish a connection and communicate. This eases the task of adding or registering a new device to the network in that the user no longer needs to perform manual input.

[0033] FIG. 2 illustrates a flow diagram of a device-controlled configuration method according to an embodiment, with the effect that one device, such as the third device 9 of FIG. 1, can configure another device, such as the complex or simple devices 4 and 5 of FIG. 1, so that those devices can connect to a network provided by AP 2. The third device 9 and the devices 4 and 5 are according to an embodiment. The case of the simple device 5 will be described as an example. While much of this description provides examples involving a network with a device such as AP 2, it should be understood that this process may also work in a peer-to-peer context. It should also be understood that the configurator may be co-located within AP 2.

[0034] An example of a device-controlled configuration method is the Device Provisioning Protocol (DPP) used in networks using Wi-Fi or IEEE 802.11, where a device acting as a DPP configurator can securely configure any Wi-Fi enabled device to connect to a Wi-Fi AP.

[0035] At S1, the process begins with two devices 9 and 5 disconnected and device 5 unconfigured. For the purposes of discussion, device 9 is used to configure device 5 to join wireless network 1, and thus device 9 may be referred to as the Configurator, and device 5 may be referred to as the Enrollee (because it has been "registered" with wireless network 1).

[0036] For example, at the start of a configuration protocol such as that specified in [DPP] or [WPS], one way for a user to verify that the configurator and enrollee running Diffie-Hellman are indeed the devices intended by the user is for at least one of these devices to make its public key available for use with Diffie-Hellman in a QR code (see [DPP]). The information in the QR code contains the so-called DPP Bootstrap URI, which contains, among other things, the public bootstrap key of the device to which the QR code belongs. Other devices can scan this QR code with their cameras and use the public key therein for Diffie-Hellman. In this way, the user performing the scan is assured that the device on which they scanned the QR code and their device run Diffie-Hellman. The DPP Bootstrap URI can also be transferred by other technologies, such as Near Field Communication (NFC) touch.

[0037] Some devices, e.g., fixed devices like access points (APs), have the problem that it is impractical to support a camera. In the case of NFC, it is impractical to perform an NFC touch between two fixed devices that are too cumbersome to move close enough to each other. Therefore, a version of the DPP standard [DPP] specifies that configurators without a camera (or NFC interface, etc.) can advertise so-called bootstrap services using mDNS (multicast DNS (Domain Name Service) [RFC 6762]). Devices on the same IP network can browse these advertisements using, for example, DNS-SD (Domain Name Service - Service Discovery) [RFC 6763].

[0038] A device with a camera, called a Bootstrap Configurator in [DPP], can be used to scan the QR code, browse mDNS, for example using DNS-SD, for the Bootstrap Service, and use that information to send the scanned public key (DPP Bootstrap URI) to the Bootstrap Service, through which the Configurator 9 retrieves it. In this way, it is as if the Configurator itself supported the camera. The Bootstrap Configurator can, of course, retrieve the DPP Bootstrap URI in any other manner, for example, by NFC touch. The Bootstrap Configurator can be implemented, for example, as an app for a smartphone. If an AP runs the Bootstrap Service, the AP, as an enrollee, can use this Bootstrap Service (and, through it, the Bootstrap Configurator) to retrieve the Configurator's DPP Bootstrap URI, or the AP can act as a DPP Configurator and use the Bootstrap Service (and, through it, the Bootstrap Configurator) to retrieve the enrollee's DPP Bootstrap URI.

[0039] The problem with DPP is that the DPP standard requires the bootstrap server to have a certificate. The bootstrap configurator can use the bootstrap server certificate to gain trust in the bootstrap service (i.e., verify that it is a legitimate service) and send the DPP bootstrap URI to the configurator's bootstrap service to set up a secure, encrypted channel. In practice, the bootstrap service is only reachable on the local network. This means that obtaining a certificate from an (intermediate) CA is difficult, and in most cases a self-signed certificate must be used. But how do you get the bootstrap configurator to trust the bootstrap service's certificate? The same problem arises when a device runs a print service and a user uses TLS or SSL with that print service to ensure that they print on the correct server and not at another house.

[0040] In S2, often called "bootstrapping," one device obtains the bootstrap public key (BR) of the other device and the devices are configured. This can be done via a method other than wireless technology, i.e., OOB. Examples of this could be a user having one device scan a responder's QR code, an NFC connection between the two devices, or another wireless technology such as Bluetooth, or a user having a bootstrap configurator obtain a DPP bootstrap URI, for example by scanning a QR code containing the DPP bootstrap URI, and then communicating this to the configurator, for example, using a Hypertext Transfer Protocol Secure (HTTPS) POST to the configurator's bootstrap service.

[0041] The bootstrap process is initiated by user intervention. If the bootstrap is successful, the process reaches S3 and the device 9, 5 is "bootstrapped"; otherwise, it returns to the "start" state in S1. In either case, the enrollee device (in this case, the simple device 5) can record the results of the bootstrap process in an appropriate storage device, for example, as a flag in a register in memory. Simple devices are often programmed to wake up after manufacture or reset, turn on their radio on the channel indicated in the configuration QR code, and begin listening for authentication request messages. (Non-simple devices are often configured into this mode by their user, for example, by resetting them.)

[0042] In S4, devices 9 and 5 perform an authentication procedure, thereby establishing "trust" with the device. That is, the user can be confident that the device is who they believe it is and not some other unknown (and potentially malicious) device "pretending" to be one or more of the devices in question. A message requesting authentication to begin is sent from one device. This message can be sent by either the device performing the configuration (configurator) or the device being configured (enrollee). In this example, a third device 9 acts as the configurator, and a simple device 5 acts as the enrollee. Note that while the third device 9 is shown connected to network 1, this is not necessary for the embodiment to function. A device that initiates wireless communication is called an initiator, and a device that responds is called a responder. In particular, the DPP protocol allows both configurator and enrollee devices to act as initiators in the DPP protocol, thereby automatically making other devices responders. Simple or headless devices typically assume the role of responder.

[0043] The other device responds to this message. If the authentication request message is decoded correctly and contains information indicating that the initiator is the device the user believes it is and has the required capabilities, the response message indicates that the message is "accepted" and indicates that the initiator contains the information necessary to verify the responder's credentials and also has the required capabilities. If the two devices do not receive the required information from the other device, the process aborts and the device returns to its bootstrapped state at S3. If the initiator is an enrollee, the authentication request message may also include an additional portion indicating the result of a previous attempt to set up the enrollee. If the responder is an enrollee, the authentication response message may include an additional portion indicating the result of a previous attempt. It should be understood that the indication also indicates whether there was a previous attempt.

[0044] In the DPP protocol, the first message is an Authentication Request message, and the response message is a DPP Authentication Response. The responder checks whether the DPP Authentication Request message contains a correctly generated cryptographic hash of the responder's public bootstrap key and a copy of the initiator's public bootstrap key. The responder sends a DPP Authentication Response message indicating whether authentication can proceed. If not, the process is aborted, for example, because an attempt to decrypt the encrypted nonce in the DPP Authentication Request message failed. The DPP Authentication Response contains a cryptographic hash of the responder's public bootstrap key and may contain a hash of the initiator's public bootstrap key. Similarly, for the initiator, the enrollee may have obtained this public key through OOB communication. The initiator's public bootstrap key can then be used for mutual authentication. Without the initiator's public bootstrap key, only the initiator can authenticate the enrollee, but not vice versa.

[0045] If the Authentication Response message indicates that the responder accepted the Authentication Request message, and the response meets the criteria imposed by the initiator's setup, the initiator issues an Authentication Confirmation message. If the authentication values ​​in the Authentication Response and Confirmation message are found to be correct by the associated devices, this part of the protocol, the authentication part, is successful and the process reaches S6, where configuration can begin. The Confirmation message may also contain an indication of the results of a previous configuration attempt in which the enrollee was also the initiator.

[0046] At S7, the enrollee device sends a configuration request message containing information about the type of configuration the enrollee requires. If the configurator can grant the request, it sends a message containing the information the enrollee requires, such as a network key. The process then ends at S8, with the enrollee being successfully configured.

[0047] In the case of DPP, the request message is a DPP Configuration Request, and the configurator's response is a DPP Configuration Response message. The DPP Configuration Response may contain the Service Set Identifier (SSID) of the network to which the enrollee will connect and may contain a DPP Connector. The DPP Connector can be considered a certificate digitally signed by the configurator and contains, among other things, the enrollee's public network access key. The DPP Configuration Response message also contains the configuration's public signing key. Other devices configured by the same configurator can thereby verify whether they can trust the other device's public network access key. The DPP Configuration Response message may also contain the network's Wi-Fi passphrase or pre-shared key (PSK). The enrollee sends a DPP Configuration Result message (depending on the DPP version) to the configurator to inform it whether it accepts the configuration. Failure of the configurator to receive this message can indicate to the configurator that there was a Wi-Fi problem between the configurator and the enrollee. The "supposedly configured" enrollee can then send its Connector to the DPP Configuration AP 2. If the connector signature is found to be correct and AP 2 has a matching connector (a connector for the same network, signed by the same configurator), AP 2 sends its connector to the enrollee. The enrollee and AP 2 can then calculate a symmetric key based on each other's network access keys in the connector and their own private Diffie-Hellman network access keys.

[0048] If the enrollee receives the Wi-Fi password or Wi-Fi Pre-Shared key (PSK), it attempts to associate with AP 2 in the normal manner via the four-way handshake specified in [802.11].

[0049] Part of the bootstrap can be provided by a so-called bootstrap configurator 10, as mentioned above. When using the bootstrap configurator 10, the configurator (AP 2 or third device 9) can also run a bootstrap service and can advertise this service using mDNS.

[0050] In the case of a local network such as that of Figure 1, the server running on device 2, 3 or 9 may in fact be a local server. The inventors have realised that this situation creates a problem.

[0051] A local server is a server that is not reachable from the global Internet and is restricted to a local network within a restricted area, for example, restricted to a building, a corporate intranet, or a home.

[0052] The URL of a local server can be found when the local network supports a local DNS (Domain Name System) server that can translate the URL into a local IP (Internet Protocol) address. Services can also be advertised on the network, for example, via mDNS (multicast DNS). When advertised, devices on the network can browse for the service (e.g., a printer service). An advertisement for a (printer) service should include information on how to reach and use the service, for example, by including the IP address of the service, the protocol used for the service, or the port number on which the service listens.

[0053] This poses a problem if a server on a local network wants to use TLS or SSL to protect its services and requires a certificate. Obtaining a certificate from an (intermediate) CA means having to prove the accuracy of the information that goes into the certificate. Proving the accuracy of local IP addresses or local URLs is difficult, since the (intermediate) CA cannot reach these. In this case, the internal server could use a self-signed certificate, but how would the client (the bootstrap configurator in the case of DPP, or the device that wants to use the print service in the case of a printer) know whether this certificate can be trusted? Even if the local server could somehow be reached from the outside, for example from the Internet, obtaining a certificate could be excessively expensive, especially in a home environment.

[0054] This problem is especially acute when the bootstrap configurator is running on the network (and therefore on a local server) for the first time: the bootstrap configurator needs to establish trust.

[0055] Figure 3 shows a process flow according to one embodiment for first-time use of the Bootstrap Configurator with a new Bootstrap Service. The purpose of this step is to establish trust; the Bootstrap Configurator will not use the Bootstrap Service if you abort the following steps.

[0056] Processing begins at S31. The configurator 2 or 9 running the bootstrap service creates a self-signed certificate that may include its own IP address or URL and may indicate that it is for the bootstrap service. Creation of the self-signed certificate, other certificates, and certificates in the certificate chain is performed using, for example, openssl [OSSL]. The configurator 2 or 9 may have created a root certificate for itself, the public key of which is used to sign a certificate that may include its own IP address or URL and may indicate that the certificate is for the bootstrap service. The root certificate is the self-signed certificate at the top of the certificate chain.

[0057] To allow a user of a bootstrap server, such as the bootstrap configurator 10, to trust the bootstrap server's certificate if its trusted certificate store does not contain the certificate itself or its root certificate, the bootstrap server can provide its certificate out-of-band (OOB). It can, for example, include its certificate in a QR code and present this QR code in some form, such as on a display, on its housing, or printed in its manual. A self-signed certificate using Brainpool 512 requires approximately 1000 octets, which seems like a lot of data for a QR code and therefore counterintuitive. However, it fits into a version 25 (117 * 117) QR code. The certificate can also be made available via near-field communication technologies such as NFC or Bluetooth. In the next step, the authenticity of the bootstrap service's certificate is checked.

[0058] At S32, the bootstrap configurator 10, which assists the configurator (e.g., 2 or 9) performing the bootstrap, attempts to find the configurator's bootstrap service via mDNS. If the bootstrap service cannot be found, the bootstrap configurator aborts the process; otherwise, it records the IP address or URL of the bootstrap service.

[0059] In S33, the bootstrap configurator 10 obtains a certificate by scanning a QR code or using NFC touch of a device that it believes will run the bootstrap service, an example of which is a local server 2, 9 or 12.

[0060] At S34, the bootstrap configurator 10 performs a signature check on the certificate. If the certificate is part of a certificate chain, the signatures of all certificates in the certificate chain (including the signature of the root certificate) are checked. If all signatures are correct, the configurator proceeds to the next step; otherwise, the configurator stops at S39.

[0061] At S35, the bootstrap configurator 10 checks whether the certificate is self-signed or part of a certificate chain, and if the certificate is self-signed, i.e., a root certificate, whether the certificate is in its trusted certificate store. If the certificate or root certificate is indeed in the store, the process proceeds to S37, where the bootstrap configurator 10 attempts to check that the certificate belongs to the bootstrap server 2 or 9; if not, the process proceeds to S36.

[0062] If the QR code contains a self-signed certificate, or if it is part of a certificate chain and the certificate or root certificate is not in its trusted certificate store, then at S36 the configurator attempts to determine whether the bootstrap service is a local service. If so, the process proceeds to S37; if not, the process stops at S39.

[0063] At S37, the bootstrap configurator 10 attempts to find the URL or IP address in the certificate or other information and matches this with information from the mDNS advertisement of the bootstrap service so found. If there is a match, the configurator trusts the bootstrap service, the certificate, and that the certificate belongs to the bootstrap service provided by server 2 or 9. The bootstrap configurator 10 can store the certificate in its store along with trusted certificates. This part of the process ends at S38 and continues to the next step in configuration. If there is not a good match, the configurator aborts the process at S39.

[0064] Below is an example of a method for checking whether the bootstrap service is a local service in S36:

[0065] First, the Bootstrap Configurator tries to get the response of the Bootstrap Service. Possible ways to do this are: The bootstrap configurator tries to get a response from the bootstrap server using a request that is guaranteed to fail, so that this response cannot do any harm, such as inject a virus into the bootstrap configurator. For example, an HTTP GET to <bootstrap server IP address> / <some big random string> can be used for this (e.g., HTTP: / / 1192.169.0.1 / ksajfafaajhcbvjahfbejfjdfnjfdfvjj); The Bootstrap Configurator can also try to get a valid response from the Bootstrap Service, but in this case it is important to note that the information in the server response is not used in any way, it is only inspected.

[0066] When a response is obtained, the bootstrap configurator can examine the hop count in the response. If it is sufficiently small, e.g., less than two, the bootstrap service is considered to be a local service. The hop count is the total number of intermediate devices, such as routers, that data must pass through from the source to the destination. If the hop count is zero, there are no intermediate devices or routers between the source and the destination. Alternatively or additionally, the bootstrap configurator can time the response time. If it is sufficiently short, e.g., less than one millisecond, the bootstrap service is considered to be a local service.

[0067] It may be advantageous to perform the procedure of FIG. 3 early in the procedure of FIG. 2, for example before, as part of, or immediately after S2 of FIG.

[0068] It should be understood that the procedure of Figure 3 can be used for services other than bootstrap services. For example, when a client device, PC4, wants to print, it can use mDNS to search for Printer 3 that runs a print service. Just as Bootstrap Configurator 10 acquires and establishes trust in the certificate of a bootstrap service provided by Configurator 2 or 9, Printer Client PC4 can acquire and establish trust in the certificate of Printer 3's print service.

[0069] Thus, a method is described for gaining trust in a local server in a network by a client, the network comprising the server, the method comprising, by the client, obtaining the server's certificate, checking whether a root certificate of a certificate chain to which the certificate belongs, or the certificate itself if it is a self-signed certificate, is in a store of trusted certificates, checking whether the root certificate, or the certificate itself if it is a self-signed certificate, is not in the trusted store, checking whether the local server is local to the network, and, if a bootstrap server is local to the network, adding the root certificate, or the certificate itself if it is a self-signed certificate, to the store.

[0070] If the server is local, it may not have access to a certificate authority. However, being local is under the user's control and can therefore be given a degree of trust. By verifying that the server is local, the client can trust the server and therefore store the certificate even in the absence of third-party authentication. By storing the certificate in a store of trusted certificates, the client can recognize the server in the future.

[0071] The server may be a bootstrap server and the client may be a bootstrap configurator, in which case the method may be advantageously used in the commissioning / configuration of devices in a network where the bootstrap uses a local server, a service running on the bootstrap server, for the bootstrap.

[0072] It is useful to perform an ownership check of the certificate to verify whether the certificate belongs to the local server, and if the certificate belongs to the local server, continue with the execution of the method, otherwise abort the execution of the method.

[0073] If the client finds that the server is not local, it is useful to terminate the method at that point, as trust cannot be established. If the server is local, the server is considered trusted.

[0074] The server may be local and not connected to a certificate authority, and this method still allows for the establishment of trust in such situations.

[0075] The client can perform a signature check on the certificate, and if the certificate is not self-signed, it performs a signature check on all certificates in the certificate chain to which the certificate belongs, and aborts execution of the method if the check results in at least one of the signatures being incorrect. Unless all signatures on the available certificates are correct, the client cannot be sure that even the local server can be trusted.

[0076] Certificates can be obtained by out-of-band (OOB) methods, which increases the level of security by allowing the transfer of information to be exchanged that is itself sensitive (i.e., should remain private to legitimately participating devices) before trust is established and encryption is set up.

[0077] The OOB method may include QR code or NFC.

[0078] An enrollee may be configured for communication over a wireless network.

[0079] Bootstrapping the enrollee may involve obtaining the enrollee's bootstrap information out-of-box.

[0080] Once trust is established, the device can proceed to execute the protocol according to the Wi-Fi Device Provisioning Protocol.

[0081] The configurator device is configured to operate in accordance with the above-described methods and may be further configured to run a local server and configure the device for communication in a wireless network.

[0082] The bootstrap configurator device is configured to function according to the methods described above and can be further configured to obtain OOB bootstrap enrollee information and communicate the enrollee bootstrap information to a bootstrap service.

[0083] Aspects of the present embodiments may be a collection of computer program instructions stored on a computer-readable storage device that can be executed by a computer, or may be embodied in a computer program product. The instructions may be any interpretable or executable code mechanism, including, but not limited to, a script, an interpretable program, a dynamic link library (DLL), or a Java class. The instructions may be provided as a complete executable program, a partial executable program, a modification (e.g., an update) to an existing program, or an extension (e.g., a plug-in) to an existing program. Furthermore, portions of the processing of the present invention may be distributed across multiple computers or processors.

[0084] Suitable storage media for storing computer program instructions include all forms of non-volatile memory, including, but not limited to, EPROM, EEPROM, and flash memory devices, magnetic disks such as internal and external hard disk drives, removable disks, and CD-ROM disks. The computer program product may be distributed on such storage media or may be made available for download via HTTP, FTP, email, or via a server connected to a network such as the Internet.

[0085] The following references can be used: [802.11] IEEE Computer Society, “IEEE Standard for Information Technology- Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” (IEEE Std. 802.11-2016), December 2016 [DH]Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEE Transactions on Information Theory, 22 (6): 644-654 [DPP]Device Provisioning Protocol - Technical Specification - Version 1.0, Wi-Fi Alliance, 2018, https: / / www.wi-fi.org / file-member / device-provisioning-protocol-specification. [OSSL]https: / / www.openssl.org / . [RD]The Resurrecting Duckling: Security Issues for Ad-Hoc Wireless Networks, University of Cambridge Computer Laboratory, https: / / www.cl.cam.ac.uk / ~fms27 / papers / 1999-StajanoAnd-duckling.pdf [RFC5297]Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES), October 2008, (https: / / datatracker.ietf.org / doc / rfc5297 / )

Claims

1. A method for gaining the trust of a server in a network, the method being performed by a client, and the method is The client obtains the server's certificate, The steps include checking whether the root certificate of the certificate chain to which the aforementioned certificate belongs, or, in the case of a self-signed certificate, the certificate itself, is in the trusted store of trusted certificates, If the aforementioned root certificate, or in the case of a self-signed certificate, the certificate itself is not present in the store, the step of checking whether the server is local to the network, If the server is local to the network, the root certificate is added to the store, and if the certificate is a self-signed certificate, the certificate itself is added to the store. If the server is not local to the network, the step of stopping the execution of the method, A method of having.

2. The method according to claim 1, wherein the server is a bootstrap server and the client is a bootstrap configurator.

3. The method according to claim 1, comprising the steps of: performing an ownership check of the certificate to verify whether the certificate belongs to the server; and continuing to perform the method if the certificate belongs to the server, and ceasing to perform the method if it does not belong to the server.

4. The method according to claim 1, wherein the server does not have a connection to the certificate authority.

5. The method according to claim 1, wherein the client performs a signature check on the certificate, and if the certificate is not a self-signed certificate, performs a signature check on all certificates in the certificate chain to which the certificate belongs, and if, as a result of the check, at least one signature is incorrect, the execution of the method is terminated.

6. The method according to claim 1, wherein the certificate is obtained using an out-of-band (OOB) method.

7. The method according to claim 6, wherein the OOB method is accompanied by a QR code or NFC.

8. The method according to claim 1, further comprising the step of setting up an enrollee for communication in a wireless network.

9. The method according to claim 8, further comprising the step of bootstrapping the enrollee by acquiring enrollee bootstrap information using the OOB method.

10. The method according to claim 1, wherein a protocol based on the Wi-Fi Device Provisioning Protocol is executed.

11. A configurator device configured to perform the method described in any one of claims 1 to 10, further configured to run a war chronicle server and to configure the device for communication in a wireless network.

12. Bootstrap configurator device configured to perform the method described in any one of claims 1 to 10, further configured to acquire OOB bootstrap enrolly information and to communicate the enrolly bootstrap information to a bootstrap service.

13. A computer program that is executed by a computer and causes the computer to perform the method according to any one of claims 1 to 10.

Images