WO2019015748A1 - Serveur, dispositif sans tête, dispositif de commande et procédés associés - Google Patents

Serveur, dispositif sans tête, dispositif de commande et procédés associés Download PDF

Info

Publication number
WO2019015748A1
WO2019015748A1 PCT/EP2017/068197 EP2017068197W WO2019015748A1 WO 2019015748 A1 WO2019015748 A1 WO 2019015748A1 EP 2017068197 W EP2017068197 W EP 2017068197W WO 2019015748 A1 WO2019015748 A1 WO 2019015748A1
Authority
WO
WIPO (PCT)
Prior art keywords
headless device
server
headless
updated setting
setting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2017/068197
Other languages
English (en)
Inventor
Benny BERGSELL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Sony Mobile Communications AB
Original Assignee
Sony Mobile Communications Inc
Sony Mobile Communications AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Mobile Communications Inc, Sony Mobile Communications AB filed Critical Sony Mobile Communications Inc
Priority to PCT/EP2017/068197 priority Critical patent/WO2019015748A1/fr
Publication of WO2019015748A1 publication Critical patent/WO2019015748A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present invention generally relates to security aspects relating to control of headless devices. More particularly, the invention relates to a server for managing headless devices, a headless device, a controller for controlling a headless device and methods relating thereto.
  • a device without a user interface or only having a very limited user interface is commonly called a "headless device".
  • Such a device typically lacks a monitor, a graphical user interface, a keyboard, a keypad, a mouse or the like, making it difficult to interact with the device.
  • One aspect of the present invention is a server for managing headless devices, comprising a processor, which is configured to receive, from a controller, which is used to control a headless device, identifying information for the headless device and at least one updated setting to be applied to the headless device, and, in response to the receipt thereof, retrieve secret information using the identifying information for the headless device, digitally sign the updated setting with the secret information, and initiate transmission of the digitally signed updated setting to the headless device in order to enable the headless device to validate that the updated setting originates from the server before applying the updated setting.
  • a second aspect of the present invention is a method for managing headless devices, comprising the steps of receiving identifying information for a headless device and at least one updated setting to be applied to the headless device, and in response to the receipt thereof, retrieving secret information associated with the identifying information for the headless device, and digitally signing the updated setting with the secret information, and initiating transmission of the digitally signed updated setting to the headless device in order to enable the headless device to validate the origin of the updated setting before applying the updated setting.
  • a third aspect of the present invention is a headless device, comprising a processor and a memory storing security information, wherein the processor is configured to receive a digitally signed, updated setting, which has been digitally signed by a server using secret information of the server, and to validate, using the security information, the origin of the updated setting, and to apply the updated setting only if it is validated that the updated setting originates from the server.
  • a fourth aspect of the present invention is a method in a headless device, comprising the steps of receiving a digitally signed, updated setting, which has been digitally signed by a server using secret information of the server; validating, using security information stored in the headless device, the origin of the updated setting; and applying the updated setting only if it is validated that the updated setting originates from the server.
  • a fifth aspect of the present invention is a controller for controlling a headless device, comprising a processor, which is configured to receive from a user, at least one updated setting to be applied in the headless device, transfer the updated setting, together with information identifying the headless device, to a server with a request for digital signing of the updated setting; to receive from the server the requested digitally signed, updated setting, and to transfer the digitally signed, updated setting to the headless device in order to enable the headless device to validate that the updated setting originates from the predetermined server before applying the updated setting.
  • a sixth aspect of the present invention is a method for managing a headless device, comprising the steps of receiving, from a user, at least one updated setting to be applied in the headless device, transferring the updated setting, together with information identifying the headless device, to a server with a request for digital signing of the updated setting; receiving from the server the requested digitally signed, updated setting; and transferring the digitally signed, updated setting to the headless device in order to enable the headless device to validate that the updated setting originates from the predetermined server before applying the updated setting.
  • FIG. 1 is a schematic block diagram of a system providing for improved security relating to control of headless devices.
  • Fig. 2 is a schematic block diagram of a headless device that may be used in the system of Fig. 1
  • Fig. 3 is a schematic block diagram of a controller that may be used in the system of Fig. 1.
  • Fig. 4 is a schematic block diagram of server that may be used in the system of Fig. 1.
  • Fig. 5 is a schematic sequence diagram, illustrating one exemplary embodiment of an operation of a system according to Fig. 1.
  • Fig. 1 shows a system including a plurality of headless devices 10, a plurality of controllers 11 and a server 12, which system allows for improved security with regard to the control of the headless devices.
  • the security aspects may be improved as will be described in further detail below.
  • the system may include only one headless device 10, one controller 11 and the server 12.
  • headless devices 10 are devices that lack a user interface or have a very basic user interface making it difficult for a user to interact with the headless devices.
  • the headless devices may be simple, low-end devices with a limited number of basic functions, like timers, humidity sensors, temperature controllers, headsets, smoke alarms and car keys. Headless devices may also include more sophisticated apparatuses that for one reason or another, e.g. size, design or location, do not have an ordinary user interface. Examples of such devices may include pacemakers, hearing aids, engines and household appliances.
  • a headless device 10 may be controlled or interacted with using a separate controller 11 having a more user-friendly user interface than the headless device it is used to interact with.
  • the controller 11 may be a dedicated device created only for interaction with a specific headless device 10. It may however also be a generic device adapted for the purpose. Typically, the controller 11 would be a smartphone with a software application that controls the interaction with the headless device.
  • the controller may be used for controlling or interacting with one or more headless devices 10 of the same kind or for controlling or interacting with two or more headless devices 10 of different types. Different controllers 11 may be used for controlling or interacting with the same headless device 10.
  • the headless devices 10 may be but are typically not connected to the Internet, i.e. the global system of interconnected computer networks that use the Internet protocol suite (TCP/IP) to link devices worldwide.
  • TCP/IP Internet protocol suite
  • All controllers 11 are configured to communicate with a server 12, which, in operation, may have access to one or more data storages that store information about the headless devices.
  • the information may in one exemplary embodiment include identifying information for the headless devices 10 managed by the server 12 and secret information which makes it possible to establish a trust between the server 12 and the respective headless devices 10.
  • the controller 11 When a user wants to change a setting of a headless device 10 in the system shown in Fig. 1, the user enters an updated setting on a user interface of the controller 11. Instead of sending it directly to the headless device 10, the controller 11 first sends the updated setting and information identifying the headless device 10 to the serverl2. The server 12 uses the identifying information to retrieve secret information, which is used to digitally sign the updated setting. The digitally signed setting is transmitted, via the controller 11, to the headless device 10, which uses security information stored in its memory to validate that the updated setting originates from the server 12. The setting is only applied in the headless device 10 if the headless device can confirm that it originates from its trusted server 12.
  • the security relating to control of headless devices can be improved.
  • the system also makes it possible to further improve the security.
  • the server may for instance check updated settings, before they are signed, to make sure that they comply with predetermined requirements.
  • the system may require user authentication and user authorization before allowing a user to see current settings of a headless device and/or update them.
  • Fig. 2 shows a schematic block diagram of a headless device 10 according to one exemplary embodiment of the invention.
  • the headless device comprises a processor 21 for operating the headless device.
  • the operation may include reading sensor values, outputting signals, turning on and off switches, and similar functions.
  • the headless device 10 further comprises a first memory 22a for storing executable instructions for the processor, a second memory 22b for storing security information, such as one or more keys of a cryptographic system, a third memory 22c for storing identifying information for the headless device, like a device ID that makes it possible to uniquely identify the headless device, at least within a group of similar devices managed by the server, and a fourth memory 22d for storing one or more settings to be used for the operation of the headless device and, in some cases, an associated token.
  • the settings include at least one that can be changed by a user to affect the operation of the headless device.
  • the first to fourth memories can be implemented in one or more different data storage units.
  • the headless device 10 may further comprise a communication unit 23, which is configured to allow for communication with a controller 11 for the headless device.
  • the communication may for example be short-range communication.
  • the communication unit may be passive, like a tag with a memory area that can be read from and written to by the controller 11 and the processor 21 of the headless device, or active in the sense that it can initiate communication and read from and write to the controller 11 or processor 21. It may or may not require a power source.
  • the short-range communication may be passive, like a tag with a memory area that can be read from and written to by the controller 11 and the processor 21 of the headless device, or active in the sense that it can initiate communication and read from and write to the controller 11 or processor 21. It may or may not require a power source.
  • Suitable communications technologies may include Near Field Communication (NFC) and Bluetooth Low Energy (BLE), but other technologies like Infrared (IR) communication, communication via sound waves, or even by a USB cable may be conceivable.
  • NFC Near Field Communication
  • BLE Bluetooth Low Energy
  • IR Infrared
  • the processor 21 is operably connected to the communication unit 22 and may be configured to make information, such as one or more current settings, a token, a device- ID or data relating to the operation of the headless device 10, available to the controller 11 and to receive information, such as a token, one or more updated settings or other data, from the controller 11.
  • the processor 21 of the headless device 10 When the processor 21 of the headless device 10 receives a digitally signed, updated setting, it validates the origin of the updated setting, by means of the security information stored in its memory.
  • the updated setting is only applied if the origin from its trusted server 12 that has digitally signed the updated setting, can be validated. In this way, it can be made sure that the updated setting originates from a trusted source and has not been tampered with during the transmission from the server.
  • Fig. 3 is a schematic block diagram of a controller 11 according to one exemplary embodiment of the invention.
  • the controller 11 comprises a processor 31, a memory 32 storing executable instructions for the processor and a user interface 33.
  • the executable instructions may be in the form of a generic or dedicated software application.
  • the user interface typically comprises a presentation unit in the form or a screen or a display. It may also include other interface elements like buttons, switches, a microphone and/or a keypad. In one embodiment a loudspeaker is used as a presentation unit.
  • the controller further comprises a communication unit 34 for communication with a headless device 10.
  • the communication unit 34 should use the same communication technology as the communication unit of the headless device and have the same communication range.
  • the communication unit 34 may be configured to receive or read information from the headless device 10 and to write information to or make information available to the headless devices 10.
  • the controller further comprises a second communication unit 35 for wireless communication with a server 12.
  • the controller 11 is an NFC-enabled smartphone which has a generic or dedicated software application for controlling interaction with a headless device 10 and a server 12.
  • the controller 11 is used by a user to control or interact with a headless device 10 by reading information from and writing information to the headless device.
  • the controller 11 is configured to forward information read from the headless device 10 and/or entered by the user to the server 12 and to transmit information received from the server 12 to the headless device 10.
  • Fig. 4 schematically shows a block diagram of a server 12 or backend system for managing headless devices.
  • the server 12 comprises a processor 41 and a memory 42 storing executable instructions for operating the server as further described in connection with Fig. 5, and a communication unit 43 for communication with one or more controllers 11.
  • the server comprises or have access to one or more data storages 44 storing information relevant for the management of the headless devices. The information may be stored in one or more databases or other data structures.
  • the information stored by the data storage(s) 44 may include one or more of identifying information for one or more headless devices 10, secret information, e.g. one or more private keys, for one or more headless devices 10, current settings of one or more headless devices 10, tokens indicative of the current settings of one or more headless devices 10, user interface specifications for one or more headless devices 10, and authentication and authorization information for one or more users of the headless devices 10.
  • the information may be stored such that it can be retrieved by means of the identifying information for the headless devices 10. Since the secret information may be more sensitive than the remaining information, it may be stored in a separate data storage with enhanced security, like a Hardware Security Module (HSM), that may also be used for generation and management of the secret information.
  • HSM Hardware Security Module
  • the sequence diagram of Fig. 5 illustrates interactions between a user, a headless device 10, a controller 11 and a server 12.
  • the headless device 10 has one or more settings that can be changed by a user. Even though the example below refers to settings in plural, it should be understood that the example is equally valid for a headless device having a single setting that can be changed.
  • NFC Near Field Communication
  • the first part 510 of the sequence diagram relates to steps carried out during a production phase in order to establish trust between the server 12 and the headless device 10.
  • these steps include generation of at least one key pair and identifying information in the form of a unique device ID (device
  • the keys are a private key and a public key of an asymmetric cryptographic system, which are generated by a key generation algorithm.
  • an asymmetric cryptographic system also known as a public key cryptographic system, is any cryptographic system that uses pairs of keys: public keys that can be disseminated to anyone and corresponding private keys that are kept secret and only known to the owner.
  • the keys can be used for two functions: authentication, which is when the public key is used to verify that a holder of the paired private key sent the message, and encryption, whereby only the holder of the paired private key can decrypt the message encrypted with the public key.
  • the device ID and the private key are stored in the database of the server 12 such that the private key can be found via the device ID.
  • the device ID, the public key that corresponds to the private key and initial settings for the headless device 10 are transferred to the headless device and stored in the headless device. The settings are applied when the headless device 10 is in operation.
  • the initial settings are also stored as current settings of the headless device 10 in the database of the server 12.
  • the production phase may include the generation of further key pairs of an asymmetric crypto system.
  • a second key pair may include a private key stored in the headless device and a corresponding public key stored in the database of the server.
  • the private key of the headless device may be used to digitally sign information transmitted from the headless device to the server so that the server may be able to confirm that data purported to originate from the headless device has not been tampered with.
  • a third key pair comprising a public key stored in the headless device and a corresponding private key stored in the server, may be generated to allow for encryption of data transferred from the headless device to the server
  • a fourth key pair comprising a public key stored in the server and a corresponding private key stored in the headless device, may be generated to allow for encryption of data from the server to the headless device.
  • One or more of the second, third or fourth key pairs may be used together with the first key pair.
  • a symmetric cryptographic system or a combination of an asymmetric and a symmetric crypto system are used.
  • two parties here the server 12 and the headless device 10
  • share a secret e.g. the same cryptographic key.
  • the requirement of a symmetric cryptographic system that both parties have access to a secret key is usually considered as a drawback compared to asymmetric cryptographic systems.
  • the server 12 also creates a token which is indicative of or represents the initial settings of the headless device 10.
  • the token may be the device ID itself.
  • the token is or includes a value representing the present settings of the headless device.
  • the token comprises both the device ID and the value representing the settings.
  • the token may also include other data, like checksums. The token may be used to minimize the amount of data which has to be read from the headless device 10. If the token includes a value representing the present settings of the headless device 10, the value may be used to verify that the current settings stored by the server 12 are the same as those in the headless device.
  • a second part 520 of the sequence diagram illustrates how settings may be read from the headless device 10 and presented to the user.
  • the user may indicate a wish to read data from the headless device 10 in different ways, e.g. by a specific gesture, pressing a button, or activating the controller.
  • the controller 11 and the headless device 10 are communicating via NFC, the user indicates the wish by putting the controller 11 close to, i.e. within NFC detection distance of, the headless device 10.
  • a request for identifying information is then transferred from the controller to the headless device.
  • the processor of the headless device responds by retrieving the requested information from the memory and making it available to the controller, either by transmitting it to the controller 11 or by storing it so that it is exposed for the controller 11 to read.
  • the identifying information may comprise the device ID or any other information that could be used to identify the headless device 10 to the server 12.
  • the identifying information is a token ("settings token"), which is made available to the controller 11 by the headless device 10.
  • the controller 11 transfers the token to the server 12.
  • the server may then use the token to identify the specific headless device 10 with which the controller has interacted and retrieve the current settings stored for the headless device in the database.
  • the server 12 may then transfer the current settings for the headless device 10 to the controller 11 so that they can be presented, e.g. displayed, to the user by the controller.
  • the server 12 may also return a specification of a user interface for presentation on the presentation unit of the controller 11.
  • the user interface specification may be specific to the headless device 10 or specific to a group of similar headless devices 10.
  • the specification may be in the form of a webpage to be displayed in a browser run by the controller 11, or it may be specific instructions expressed in a language suitable for the purpose and based on which the controller 11 can render the user interface.
  • the specification includes instructions for an audio presentation. In this way a generic software application can be used for different types of headless devices requiring different user interfaces.
  • the server 12 may also transfer the device ID to the controller 11.
  • the database 44 of the server 12 stores the same settings as are used in the headless device 10 itself. This means that the settings need not be transferred from the headless device 10 to the controller 11, but can be retrieved from the server 12 when they should be presented to the user.
  • the token is the only information that has to be transferred from the headless device 10 to the controller 11 in order to enable display of the settings of the headless device. This may be advantageous if the transfer speed is low and/or the amount of data to transfer is high.
  • the settings can be read in full from the headless device 10 together with identifying information for the headless device. In such case there is no need for the database of the server 12 to store the current settings of the headless device.
  • the identifying information may
  • the third part 530 of the sequence diagram illustrates a process for making changes to the settings of the headless device 10.
  • the process starts by the user changing one or more of the settings presented on the user interface of the controller 11.
  • the controller 11 receives the updated settings, it sends a request to the server 12 for signing of the settings.
  • the request may include the updated settings and the device ID of the headless device 10.
  • the processor 41 of the server 12 retrieves the private key associated with the headless device 10 identified by the device ID from the database and digitally signs the settings using the private key before initiating transmission of the digitally signed updated settings to the headless device 10 by returning the updated settings to the controller 11 .
  • the controller 11 When the controller 11 is activated for communication with the headless device 10, in this example when the user places the controller within the communication range of the headless device, the digitally signed, updated settings are transferred to the headless device, which validates that the settings originates from the trusted server 12 and that they have not been tampered with.
  • the validation is carried out by means of a signature verifying algorithm and the public key which is stored in the memory of the headless device and which corresponds to or is paired with the private key used in the server 12 for digitally signing the updated settings. If the headless device 10 confirms the signature of the trusted server 12, the settings are stored in the memory 22d of the headless device 10 and applied by the processor 21 when operating the headless device. The headless device 10 then sends a confirmation to the controller 11 that the updated settings have been successfully applied. If the headless device is unable to confirm that the settings originate from the trusted server 12, they are discarded and a message to that effect is returned to the controller 11.
  • the device ID is included in the digitally signed message from the server 12 and the headless device 10 checks the device ID in the message against the device ID stored in its memory to verify that the updated settings are intended for this headless device.
  • the data storage 44 accessible by the server 12 stores one or more different requirements that the settings for the different headless devices 10 have to comply with.
  • requirements may include permitted intervals for numerical values, allowable combinations of settings, and compatibility with a firmware version used in the headless device.
  • the processor 41 of the server 12 may be configured to check the received updated settings against the stored requirements in order to make sure that the updated settings can be validly applied to the headless device 10. If the settings pass the check, then the settings are digitally signed as described above. If not, the server 12 may send a message to that effect to the controller 11.
  • the processor 41 of the server 12 updates the data storage 44 with the updated settings, if appropriate after the settings have been successfully tested against the predetermined requirements.
  • the processor 41 of the server 12 calculates a delta or a difference between the updated settings and the current settings and only the delta or difference is transferred to the controller 11 and further to the headless device 10.
  • the delta is calculated in the controller 11 and only the delta is sent to the server 12.
  • a new token may be created by the processor 41 when the settings are successfully updated on the server 12.
  • the processor stores the token in the data storage in association with the updated settings and provides for the transmission of the updated token, together with the updated settings, to the headless device 10 via the controller 11.
  • At least one key pair is created for each headless device 10.
  • the server 12 uses a separate private key for each headless device 10.
  • a common key pair is created for all the headless devices 10 so that all the headless devices have the same public key and the server has a single private key.
  • the server 12 is about to digitally sign an updated setting, it uses the common private key and the device ID of the headless device 10 to create a private key that is unique for the headless device.
  • the headless device 10 is about to validate the digitally signed, updated setting, it uses the common public key and the device ID to generate a public key paired to the unique private key generated by the server 12.
  • authentication of the user is required before the user is allowed to change the settings of the headless device.
  • the authentication is made in conventional and well-known manner by the user providing proof that he really is who he claims to be.
  • user authentication is required already for viewing the current settings of the headless device.
  • the authentication step may also include an implicit or explicit check that the user is authorized to change the settings of the specific headless device.
  • the user has to prove its identity to the server 12. This may be done by the user providing a user name and a password to the server, which checks the name and the password against previously registered information.
  • the name and password may be provided through a user interface of the controller.
  • Other ways to authenticate can be by means of biometrics, such as fingerprints or voice recognition, or by means of one-time codes generated by the controller or a different device.
  • Authorization is in this case used to establish which headless device(s) 10 a user has the right to interact with.
  • the server 12 may check the user's authorization against previously registered information associated with the user' s identity. Authentication information and authorization information may be stored in a data storage in the server 12 or elsewhere where it is accessible for the server.
  • the system described above includes at least three layers of security.
  • a first one is the digital signing by the server 12 of updated settings, which means that the headless device 10 may validate the settings.
  • a second one is the check, by the server 12, of the validity of the updated settings suggested by the user, which means that unreasonable and harmful settings may be prevented from being applied to the headless device 10.
  • a third one is the requirement for user authentication and/or authorization, which means that only pre-approved and registered users can update settings of a headless device 10.
  • All information transferred by the different components of the system can be made available unencrypted, encrypted and/or digitally signed depending on how the system has been set up during production.
  • a server 12 for managing headless devices 10 comprising a processor 41 which is configured to receive, from a controller 11, which is used to control a headless device 10, identifying information for the headless device 10 and, in response to the receipt thereof, retrieve, using the identifying information, at least one current setting of the headless device 10 and transmit the retrieved at least one current setting to a presentation unit 33 for presentation to a user.
  • the idea may also be embodied by a controller 11 for a headless device 10, comprising a processor 31 which is configured to read identifying information from the headless device 10 and transmit it to a server 12, and to receive , from the server 12, at least one current setting of the headless device 10 identified by the identifying information, and to present the current setting on a presentation unit 33.
  • the idea may be embodied by a method for interacting with a headless device 10, comprising the steps of receiving, from the headless device 10, information identifying the headless device 10; transmitting the identifying information to a server 12; receiving from the server 12, at least one current setting of the headless 10 device identified by the identifying information; and presenting the current setting on a presentation unit 33.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un serveur (12) permettant de gérer des dispositifs sans tête (10) qui comprend un processeur (41), qui est configuré pour recevoir, d'un dispositif de commande (11), qui est utilisé pour commander un dispositif sans tête (10), des informations d'identification pour le dispositif sans tête (10) et au moins un réglage mis à jour à appliquer au dispositif sans tête (10). En réponse à la réception de celui-ci, le processeur est en outre configuré pour récupérer des informations secrètes à l'aide des informations d'identification pour le dispositif sans tête (10), pour signer numériquement le réglage mis à jour avec les informations secrètes, et pour initier la transmission du réglage mis à jour signé numériquement au dispositif sans tête (10) afin de permettre au dispositif sans tête (10) de valider que le réglage mis à jour provient du serveur (12) avant l'application du réglage mis à jour. L'invention concerne également un dispositif de commande, un dispositif sans tête et des procédés associés.
PCT/EP2017/068197 2017-07-19 2017-07-19 Serveur, dispositif sans tête, dispositif de commande et procédés associés Ceased WO2019015748A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/068197 WO2019015748A1 (fr) 2017-07-19 2017-07-19 Serveur, dispositif sans tête, dispositif de commande et procédés associés

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/068197 WO2019015748A1 (fr) 2017-07-19 2017-07-19 Serveur, dispositif sans tête, dispositif de commande et procédés associés

Publications (1)

Publication Number Publication Date
WO2019015748A1 true WO2019015748A1 (fr) 2019-01-24

Family

ID=59485329

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/068197 Ceased WO2019015748A1 (fr) 2017-07-19 2017-07-19 Serveur, dispositif sans tête, dispositif de commande et procédés associés

Country Status (1)

Country Link
WO (1) WO2019015748A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025256996A1 (fr) * 2024-06-12 2025-12-18 Inventio Ag Procédé et système de restauration vérifiable de configuration d'un dispositif ; dispositif et dispositif utilisateur

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100275026A1 (en) * 2009-04-27 2010-10-28 Mclean Ivan H Method and apparatus for improving code and data signing
US20150271208A1 (en) * 2014-03-24 2015-09-24 TrustPoint Innovation Technologies, Ltd. Management and distribution of security policies in a communication system
US20170180391A1 (en) * 2015-12-22 2017-06-22 Mcafee, Inc. Secure over-the-air updates

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100275026A1 (en) * 2009-04-27 2010-10-28 Mclean Ivan H Method and apparatus for improving code and data signing
US20150271208A1 (en) * 2014-03-24 2015-09-24 TrustPoint Innovation Technologies, Ltd. Management and distribution of security policies in a communication system
US20170180391A1 (en) * 2015-12-22 2017-06-22 Mcafee, Inc. Secure over-the-air updates

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Simplifying IoT: Connecting, Commissioning and Controlling with Near Field Communication (NFC", WHITE PAPER, June 2016 (2016-06-01)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025256996A1 (fr) * 2024-06-12 2025-12-18 Inventio Ag Procédé et système de restauration vérifiable de configuration d'un dispositif ; dispositif et dispositif utilisateur

Similar Documents

Publication Publication Date Title
KR102509688B1 (ko) 디지털 신원 인증 방법, 장치, 기기 및 저장 매체
CN112214745B (zh) 经认证的外部生物特征读取器和验证设备
US7185199B2 (en) Apparatus and methods for providing secured communication
US11026085B2 (en) Authentication apparatus with a bluetooth interface
KR101718824B1 (ko) 액세스 제어
KR102202547B1 (ko) 액세스 요청을 검증하기 위한 방법 및 시스템
CN111324672A (zh) 区块链安全处理系统及方法
US20160057134A1 (en) Updating of a Digital Device Certificate of an Automation Device
JP2015057704A (ja) ユーザ認証情報の配信
WO2011147204A1 (fr) Procédé de commande de garde d'entrée et système associé
JP2009212731A (ja) カード発行システム、カード発行サーバ、カード発行方法およびプログラム
JP2024504036A (ja) バーチャルキーの共有システム及び方法
US20140013116A1 (en) Apparatus and method for performing over-the-air identity provisioning
JP2015194879A (ja) 認証システム、方法、及び提供装置
JP6264626B2 (ja) 証明書発行システム、通信方法及び管理装置
WO2019015748A1 (fr) Serveur, dispositif sans tête, dispositif de commande et procédés associés
KR102402558B1 (ko) 신원인증 단말장치
KR102497440B1 (ko) Did 기반의 사용자 정보 관리 서비스 제공 방법 및 시스템
CN116028954A (zh) 允许访问安全数据的设备
KR102118956B1 (ko) 인증 시스템 및 방법
JP7379400B2 (ja) 情報処理システム、サーバ装置、情報処理方法及びプログラム
KR102309044B1 (ko) 메시지 처리 시스템에서 보안 채널 형성 장치 및 방법
KR20180049455A (ko) 차량용 모듈의 정품 인증 방법 및 장치
KR20160020314A (ko) 전자서명을 이용하여 대출서비스를 제공하기 위한 장치 및 그 방법
HK1261951B (zh) 数据密钥的保护方法、装置和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17745679

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17745679

Country of ref document: EP

Kind code of ref document: A1