GB2508892A - Updating a trusted device by booting update software and downloading the update over a network - Google Patents

Abstract

A user trusted device 10 is connected to a host computer 101 and the host computer is booted from the device. The boot firmware 122 of the computer detects that the device contains a bootable partition and loads the update software from the device into the computer memory 121. The update software transfers an update for the software on the device from a network server 30 to the computer and updates the software in the device. The update software may use the network interface 124 in the host computer if the device does not have a network interface. The device may have a secure memory and a non-secure memory. The non-secure memory may be encrypted using a key stored in the secure memory.

Description

tM:;: INTELLECTUAL

PROPERTY OFFICE

Application No. 0B1222581.9 RTM Date:3 July 2013 The following terms are registered trademarks and should be read as such wherever they occur in this document: Firewire Thunderbolt Java Intellectual Properly Office is an operaling name of Ihe Patent Office www.ipo.gov.uk

NETWORK UPDATABLE USER TRUSTED DEVICE

FIELD Of THE INVENTION

The invention relates in general to the field of user trusted devices equipped with a connection interface for connecting to a host computer, and in particular to software update methods for updating such devices via a network.

BACKGROUND Of THE INVENTION

User trusted devices (including secure, tamper proof devices) are generally known. For example, for online transactions, a solution which has been developed is the so-called Zone Trusted hiformation Channel (or ZTIC for short). The ZTIC is a secure, non-programmable device for the authentication of transaction data. Since the ZTIC maintains a secured end-to-end network connection to the server, the ZTIC itself is tamper-proof against malicious software attacks and as it has its own input and output components independent of the host it connects to, the data shown on the ZTIC display is genuine. More details can be found in e.g., The Zurich Trusted Information Channel -An Efficient Defence against Man-in-the-Middle and Malicious Software Attacks, by Thomas Weigold, Thorsten Kramp, Reto Hermann, Frank Ho*ring, Peter Buhler, Michael Baentsch. In P. Lipp, A.-R. Sadeghi, and K.-M. Koch (Eds.): TRUST 2008, LNCS 4968, pp. 75-91, 2008. Springer-Verlag Berlin Heidelberg 2008.

Some secure devices that have a built in network card (e.g., routers, storage attached network devices) provide a functionality to be network updatable. These devices, however, need their own network connection.

Other devices use a secure channel through a PC to be updatable (such as the Migros banking memory stick, see e.g., bank-launches-new-system-for-safer-c-hanking.htmi?t.x ttnews%SBbackPid%5D=596&cHash=4180355h72). However, these devices require a given operating system to be available on the PC for the update to be successful.

BRIEF SUMMARY Of THE INVENTION

According to a first aspect, the present invention is embodied as a user trusted device comprising: a connection interface enabling connection with a host computer; a persistent memory storing a boot enabling data structure and a network updater.

wherein, the network updater is configured to interact, upon execution at a host computer, with a firmware of the host computer to initiate a communication over a network to which the host computer is connectable; and the boot enabling data structure: is detectable by the firmware upon connection of the user trusted device with said host computer; is such that the host computer can boot from the user trusted device, preferably as per the data structure of the boot enabling data structure; and comprises instructions for the firmware to initiate a transfer of said network updater on the host computer for subsequent execution at the host computer, upon the host computer booting from the user trusted device.

In embodiments, said network updater is configured to interact, upon execution at said host computer, with said firmware of the host computer to subsequently interact with a network card of the host compute!', in order to initiate said communication over the network as enabled by said network card, Preferably, the network updater comprises a reference to a server to be contacted upon initiating said communication over the network, In preferred embodiments, said user trusted device comprises no network card (or more generally is lacking networking functionality).

Preferably, said persistent memory comprises: a secure memory, onto which is stored a first part of the network updater; and a non-secure memory, onto which is stored a second part of the network updater.

In embodiments, the second part of the network updater resides encrypted on the non-secure memory, a corresponding encryption key being stored on the secure memory.

Preferably, the second part of the network updater occupies less than half a size of the secure memory, said memory size preferably less than or equal to 256 ko, more preferably less than or equal to 128ko.

In preferred embodiments, said network updater is configured to interact, upon execution at a host computer, with a firmware of the host computer to initiate said communication, said firmware being one of the following: BIOS, preferably with a PXE BIOS; Extensible Firmware Interface BIOS; or Unified Extensible Firmware Interface BIOS.

Preferably, said connection interface is of one of the following types: Universal Serial Bus or USB; External Small Computer System Interface or SCSI; External Serial Advanced Technology Attachment or SATA; Firewire; or Thunderbolt.

The present invention can further be naturally embodied as a system comprising: a user trusted device according to any one of the above embodiments; a server to be contacted upon initiating communication over the network, the network updater of the user trusted device comprising a reference to said server; and, preferably, the host computer.

According to another aspect, the present invention can be embodied as a method for initiating communication between a user trusted device according to any one of the above embodiments and a network, the user trusted device connectable to a host computer. said host computer connectable to said network, the method comprising: letting the boot enabling data structure of the user trusted device be detected by the firmware of the host computer, in order to make the host computer boot from the user trusted device, for subsequently transfernng the network updater at the host computer, such as for the network updater to execute at the host computer and interact with the firmware to initiate a communication over said network.

Preferably, said method further comprises: causing said network updater to interact with said firmware of the host computer to subsequently interact with a network card of the host computer, in order to initiate said communication over the network as enabled by said network card.

Preferably too, the method further comprises: contacting a server referenced by the network updater, upon initiating said communication over the network.

In embodiments, the method further comprises: transferring data, preferably a user trusted device firmware update, from the server to the user trusted device; stonng said transferred data on a memory, preferably a persistent memory, of the user trusted device; and preferably, updating software of the user trusted device according to the transfelTed data as stored on the memory of the user trusted device.

According to a final aspect, the invention is embodied as a computer program product for initiating communication between a user trusted device and a network, the computer program product comprising a computer-readable storage medium having a boot enabling data structure and a network updater embodied therewith, wherein, the network updater is configured to interact, upon execution at a host computer, with a firmware of the host computer to initiate a communication over a network to which the host computer is connectable; and the boot enabling data structure: is detectable by the firmware upon connection of the user trusted device with said host computer; is such that host computer can boot from the user trusted device, preferably as per the data structure of the boot enabling data structure; and comprises instructions for the firmware to initiate a transfer of said network updater on the host computer for subsequent execution at the host computer, upon the host computer booting from the user trusted device.

Devices, systems and methods embodying the present invention will now be described, by way of non-limiting examples, and in reference to the accompanying drawings.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

-FIG. I represents a general computerized system, suited for implementing method steps as involved in embodiments of the invention; -FIG. 2 illustrates chosen components of the computerized system of FIG. I, together with a flowchart illustrating steps of a method, according to embodiments; -FIG. 3 is a simplified representation of selected components of a secure device according to embodiments, and how these components intelTelate functionally; and -FIG. 4 is a flowchart illustrating high-level steps of a method for initiating communication between a secure device and a network, according to embodiments.

DETAILED DESCRIPTION OF THE INVENTION

The following description is structured as follows. First, general embodiments and high-level variants are described (sect. I). The next section addresses more specific embodiments and technical implementation details (sect. 2).

1. General embodiments and high-level variants FIG. 1 represents a general computerized system. suited for implementing method steps as involved in embodiments of the invention.

It will be appreciated that the methods described herein are argely non-interactive, and automated by way of computerized systems, such as servers or embedded systems. In exemplary embodiments, the methods described herein can be implemented in a (partly) interactive or non-interactive system. These methods can further be implemented in software (e.g., firmware), hardware, or a combination thereof. lii exemplary embodiments, the methods described herein are implemented iii software, as an executable program, and is executed by a special or general-purpose digital computer. such as a personal computer, workstation, minicomputer, or mainframe computer. The most general system 100 therefore includes general-purpose computer 101.

In exemplary embodiments, in terms of hardware architecture, as shown in FIG. 1, the computer 101 includes a processor 105, memory 110 coupled to a memory controller 115, and one or more input and/or output (110) devices (or peripherals) 10, 145 that are communicatively coupled via a local input/output controller 135. The input/output controller 135 can be, but is not limited to, one or more buses or other wired or wireless connections, as is known in the art. The input/output controller 135 may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, andlor data connections to enable appropriate communications among the aforementioned components. As described herein the 110 devices 10, 145 may generally include any generalized cryptographic card or smart card known in the art.

One of these devices is a user trusted device 10, discussed below in detail.

The processor 105 is a hardware device for executing software, particulady software that is stored in memory 110. The processor 105 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computer 101, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions.

The memory 110 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile (persistent) memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory 110 may IS incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 110 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 105. In particular, memory shall include a memoiy portion 121 to which the network updater 15 can be transferred, in whole or in part, for subsequent execution.

The software in memory 110 may include one or more separate programs, each of which comprises a Usting of executable instructions for implementing logical functions, notably functions involved in embodiments of this invention. In the example of FIG. I, memory 110 may be loaded with software including instructions for implementing methods for initiating communication between the user trusted device 10 and a network 165.

The software in memory 110 may also typically include a suitable operating system (OS) 111, even if the novel methods discussed here ignores the OS of the host 101 (they operate at another level, closer to hardware, whereby the normal behavior of the computer 101 is impacted). Once (and if) loaded, the OS 111 essentially controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

At least part of the methods described herein may be in the form of a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program needs to be translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory of the device 10 and/or host 101. Furthermore, the methods can be written as an object oriented programming language. which has classes of data and methods, or a procedure programming language. which has routines, subroutines, and/or functions. In all cases, the novel methods discussed herein are designed so as to operate properly in connection with the firmware 122, and with the device's CPU 11 if needed.

In exemplary embodiments, a conventional keyboard 150 and mouse 155 can be coupled to the input/output controller 135. Other output devices such as the 110 devices 145 may include input devices, for example but not Umited to a printer, a scanner, microphone, and the like.

Finally, the 110 devices 10. 145 may further include devices that communicate both inputs and outputs, for instance but not limited to, a network interface card (NIC) or modulator/demodulator (for accessing other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, and the like. As described herein the 110 devices 140, 145 can be any generalized cryptographic card or smart card known in the art. The system 100 can further include a display controller 125 coupled to a display 130. In exemp'ary embodiments, the system 100 can further include a network interface 160 for coupling to a network 165. The network 165 can be an IP-based network for communication between the computer 101 and any external server, client and the like via a broadband connection. The network 165 transmits and receives data between the computer 101 and external systems, e.g., a server 30. In exemplary embodiments, network 165 can be a managed IP network administered by a service provider. The network 165 may be implemented in a wireless fashion, e.g., using wireless protocols and technologies, such as WiFi, WiMax, etc. The network 165 can also be a packet-switched network such as a local area network, wide area network, metropolitan area network, Internet network. or other similar type of network environment. The network 165 may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN) a personal area network (PAN), a virtual private network VPN), intranet or other suitable network system and includes equipment for receiving and transmitting signals.

If the computer 101 is a PC, workstation, intelligent device or the like, the software in the memory 110 may further include a basic input output system (BIOS) 122. The BIOS is a set of essential software routines that initialize and test hardware at startup, start the OS 111, and support the transfer of data among the hardware devices. The BIOS is typically stored in ROM so that the BIOS can be executed when the computer 101 is activated.

For the purpose of implementing methods as described herein, the BIOS 122 can be used to initiate a communication over a network 165 to which the host computer 101 is connectable.

More generally though, any suitable firmware 122 or interface to a firmware (i.e., a combination of persistent memory and program code and data stored therein, which operates "below" the operating system 111 in the software stack), can be used to that aim. This typically is the BIOS. 1-lowever, examples of suitable firmwares 122 or interface thereto include a Preboot eXecution Environment (PXE) BIOS, the so-called Extensible Firmware Interface (ER) BIOS or, still, the Unified Extensible Firmware Interface (UEFI). The latter is a specification that defines a software inteiface between the operating system and the platform firmware. UEFI is meant to replace the BIOS firmware interface, present in all IBM PC-compatible computers today. In practice, most UEFI images have legacy support for BTOS services. More generally, any firmware having legacy support for BIOS services or comparable services can be contemplated for the purpose of implementing methods described herein. Even more generally, any firmware, e.g., initialization firmware, capable of initiating a communication over a network, e.g., via interaction with a network card of the host computer (e.g., to initialize the network card), and operating below the operating system in the software stack could convene for the purpose of implementing the present invention.

When the computer 101 is in operation, the processor 105 is configured to execute software stored within the memoty 110, to communicate data to and from the memoiy 110, and to generally control operations of the computer 101 pursuant to the software. The methods described herein, in whole or in part, but typically the latter, are read by the processor 105, possibly buffered within the processor 105, and then executed.

The portions of the methods described herein that can be implemented in software can be stored on any computer readable medium for use by or in connection with any computer related system or method.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely firmware andlor software embodiment (firmware, resident software, micro-code, etc.) or an embodiment combining firmware/software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium wo&d include the following: an electrica' connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" progranrniing language or similar programming languages. The program code may execute entirely on the users computer, or partly on the users computer (as a stand-alone software package), or still partly on two or more of the following: the user's computer, the user trusted device, and a remote computer.

The host computer and the server may be connected through any type of network, including: local area network (LAN); wide area network (WAN); connection to an external computer (Internet, using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions.

These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer. other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment. or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially conculTently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Referring generally to FIGS. I to 4, an aspect of the invention is first described, which concerns a secure device 10 (or more generally a user trusted device). This device is a corporate or personal device, that is, a device that a company or a user owns and controls, such as a USB device, preferably a USB flash drive (a data storage device that includes flash memory, in addition to an integrated Universal Serial Bus (USB) interface), a mobile phone or a personal digital assistant (PDA) that only this user uses or that is owned and controlled by the company this user works for. Typica'ly. this device weighs less than 100 g, preferably less than 60 g and more preferably less than 40 g. Additional aspects of this device 10 that may contribute to make it "secure" shall be discussed later.

At least, this device compnses: -a connection interface 12 enabling connection S2 with host computer 101; and -a persistent memory 14 storing notably two components: a boot enabling data structure 16 and a network updater 15. which are designed to interact as follows.

First, the network updater 15 is software to be executed on the host computer 101. More precisely, it is configured to interact, upon execution at the host 101, with the firmware 122, e.g., the BIOS, of the host computer to initiate a communication over a network 165 to which the host computer is connectable. Thus, the network updater 15 shall execute on the host computer 101 upon booting, i.e., before the operating system is loaded. In other words, the operating system is bypassed: the network updater sha'l execute and be able to perform its natural function, i.e., updating, without the operating being involved. In practice, the updater is a small software update program, which may e.g., be stored inside the device firmware.

Second, the boot enabling data structure 16 (also referred to as a boot loader below) is detectable by the firmware 122 upon connection of the secure device 10 with said host computer 101. The boot loader is furthermore designed such that host computer 101 can boot from the secure device 10, upon restarting. This functionality can for instance be provided as per the data structure of the boot loader itself, as known per Se. Finally, the boot loader 16 comprises instructions for the firmware 122 to initiate a transfer of said network updater 15 on the host computer 101 for subsequent execution at the host computer 101, upon the host computer booting from the secure device 10.

Transfer in this context means that the firmware initiates the action of storing the network updater on a suitable host computer's memory portion 121, e.g., this preferably occurs when one or more (e.g., a few) first blocks of the network updater are being read by the host 101.

Thus, to summarize: the boot loader 16 is detectable by the firmware (BIOS) 122 upon connection of the device 10 to the host 101, whereby the host can boot from the secure device 10. The boot loader 16 comprises instructions for the firmware 122 to initiate a transfer of the network updater 15 on the host 101 for subsequent execution at the host computer 101, upon booting. When executing at the host 101, the network updater 15 interacts with the firmware (BIOS) 122 to initiate a communication over the network 165.

Such a solution makes the device 10 easily updatable from the network, even if the device 10 is not equipped with a network card or more generally has no direct network access. In fact, the device 10 is preferably not equipped with such direct network access means, a thing that allows for simpler and cheaper designs for this device 10. No specific software/OS is furthermore required on the host 101 for performing the update, beyond the firmware 122. In fact, the host 101 may be empty, even without any hard drive.

The host 101 boots from the device 10, which can in turn make use of the computers built-in network card (or more generally network access means) in combination with the computer's BIOS, or any similar firmware (PXE BIOS for culTent computers, EEl or UEFI BIOS for future computers).

No trace is left on the hosting computer. In addition, any user can easily update the device 10 to perform different/new functionaities at the device 10. This solution enables extremely simple update processes e.g., insert the device 10 into a computer 101, restart, choose the new functionality. No special hardware/software/knowledge is required to reconfigure the device.

The hardware can always stay the same.

This device 10 can further be tuned to different application scenarios, beyond the mere software updates. Not all the software on the device 10 has to be stored in a secure storage.

The software updates and parts of the application updater may be stored on a simp'e SD card.

However, updates or changes of functionality can still be performed securdy even though it may partly rely on an otherwise insecure SD card (as discussed in reference to some embodiments below).

For instance, the update can be brought securely into the device, e.g., by means of -An HTTP connection from server to device 10 through computer 101; -End-end authentication; -Signature and other encryption data 13 can be stored in a secure memory on the device; -Payload may be stored on a SD card; and -Verification can be performed during a next access.

In contrast, any comparable prior art device so far requires either: U) a specific software on the PC 101 to update the device, which specific software needs to be written for various OSs and need to be run from within the OS, leading to compatibility issues. Also, one question that raises as to the security concern is whether one can trust the OS; or (ii) to put the software update on an SD card and insert the card into an SD card slot, which type of solutions is not at all practical and is more expensive, since it: a. requires an extra SD card slot or the like; b. is cumbersome, needs to be prepared manually; and c. does not make it easy for the update to be controlled from a central server.

Referring now to FIGS. 1 and 2: preferably, a network card 124 of the host computer 101 is relied upon in the process. Namely: the network updater 15 is preferably configured to interact, upon execution at the host 101, with firmware 122 to subsequently interact with a network card 124 (e.g., to initialize the network adapter) of the host 101, and this, in order to initiate the communication over the network, which is otherwise enabled by the network card 124. Still, other 110 devices could be used to achieve the same.

The network updater 15 may comprise a reference to a server 30 to be contacted upon initiating the communication over the network. This reference may for instance be hardcoded in the updater 15. More generally, the updater 15 may comprise any suitaNe means (algorithm, etc.) for determining the server.

Naturally, the present invention extends to a general computerized system such as depicted in FIG. 1 or 2, i.e., comprising: a secure device 10, the server 30 and preferably the host computer 101.

In terms of method steps, the invention can be embodied as follows, i.e., as a method for initiating communication between the secure device 10 and a network 165. Such a method is now described in reference to FIG. 4: -First (step Sl), a system such as evoked above is provided, which, broadly, includes the secure device 10, the host 101, a network 165 to which the host can be connected; -Second (step S2), the secure device 10 is connected to the host 101, the host 101 is (re-)started. The computer needs be (re-)started after connecting the device 10 thereto, or otherwise put into a state that allows it to start from the external device, e.g., the following options are therefore possible: * Computer 101 is shut-off; plug device 10; start computer; or * Computer 101 already running; plug device; restart computer -Step S3: the boot enabling data structure of the secure device 10 is detected S3 by the firmware 122 of the host computer 101; -Step 53a: the host computer 101 boots from the secure device 10; -Subsequenfly (step S4), the network updater 15 is transferred to the host 101, for instance to memory portion 121, whereby o Step S5, the network updater 15 executes at the host computer 101; and o interacts (step S6) with the firmware 122, o to initiate (steps S7, S7a, S7b) a communication over the network 165.

Preferably, where a network card is involved, the network updater 15 shall interact with said firmware 122 (at step S6) to subsequently interact (step S7a) with the network card 124 (e.g., to initialize the network adapter) of the host 101, in order to initiate (step S7b) said communication over the network as enabled by said network card.

For illustration, examples of instructions used by the updater 15 to initialize a PXE BIOS include but are not limited to: Algorithm: Initialization of the PXE BIOS by the updater Load UNDI ROM

PXENY_START_UNDI

PXEN V_UND 1_STARTUP

PXENV_UNDI_INITIALIZE

PXEN V_UND 1_OPEN An additional instruction (e.g., PXENV_UNDI_TRANSMIT) could be appended to send packets to the server, via the network card. By way of such instructions, the network updater interacts, upon execution at the host, with the PXE BIOS 122 to initialize the network card 124, whereby a communication can be initiated over the network.

Similar instructions are provided by EFI and UEFI BIOSes in the EFI_SIMPLE_NETWORK API (Initialize, Start, Stop, Receive, Transmit). BIOSes may also provide higher level protocol implementations of the TCP/IP stack and other networking protoco's which may be used as well.

As said earlier, said communication is preferably initiated for contacting (step S7c) a server 30, which can be determined thanks to the network updater 15, upon initiating the communication over the network.

Amongst the various applications that can be contemplated with the present invention, subsequent steps would preferably consist in: -transferring data (steps S8, S8a -S8d), preferably a secure device firmware update, from the server 30 to the secure device 10; -storing (step S8d) the transferred data on a memory (persistent or not) of the secure device 10; and, preferably.

-updating (step S9) software of the secure device (e.g., firmware) according to the transferred data as stored on the memory of the secure device 10.

Different types of software (be it firmware, control software, or only parts thereof) may be contemplated here; such software may be stored on the device and shall preferably be updated as update units.

Thus, a typical scenario is the following: the device 10 is first connected to the computer 101 and the computer is restarted. When restarted, the computer boots from the device and starts the network updater, after having transferred the updater from the device. Then, the updater interacts with the BIOS to use the network card of the computer, in order to establish a secure network connection to a server and retrieve updates. Updates are transferred back to the device for it to update one or more update units stored on the device. In most simple scenarios, an update is dowftloaded, which allows new/updated functionalities to be implemented at the device 10. After an update, the device may for instance include new banking functionalities or Secure Enterprise Desktop functionalities. More generally, the device 10 can be updated to perform different operations using the network update.

Yet, beyond the mere update of existing functionalities, other applications can be contemplated. where a boot loader prompts the host to transfer and execute the network updater. configured to interact with a firmware to initiate a communication. In this respect, let us remind that "network update?' is a name given to some software piece, initially located on the device 10, and whose function is, in the context of this invention, most generally to interact, upon execution at the host, with a firmware thereof to initiate a communication over a network to which the host is otherwise connectable. This function accordingly allows for performing some "update" via a network, even though the device 10 lacks networks capacity.

In addition, note that, notwithstanding the diagram of FIG. 2, the path taken by the update data (step S8) downloaded from the server 30 can be exactly reversed to the path taken to initiate the communication with the server 30 (steps S3 -S7), or not. In particular, the update data may be buffered in another portion of memory than portion 121.

Next, refernng back to and as touched earlier, the persistent memory i4 shall preferably comprise: -a secure memory 141, onto which is stored a first part 151 (or given portions) of the network updater 15; and -a non-secure memory 142, e.g., a SD card, onto which is stored a second part 152 (or other portions) of the network updater 15.

The presence of a secure memory contributes to make the user trusted device a secure device.

For example, a part of the network updater 15 may reside encrypted on the non-secure memory 142, while a corresponding encryption key is stored on the secure memory 141. The secure memory is typically limited to 128 ko or 256 ko, for cost reasons. It can thus preferably be used to merely store encryption data. e.g., hashes/signatures. Part 151 of the updater can therefore reside on the secure memory 141 while other parts 152 of the updater 15 shall reside encrypted on the non-secure memory. Similarly, the boot loader 16 can reside on the SD card too, yet encrypted with signature residing on the secure memory 141. When the host computer 101 requests a given block or any data chunk of the boot enabling structure, then the device's CPU II shall be prompted by software residing in memory 14 to decrypt the requested block, e.g., using encryption data stored on the secure memory 141.

Preferably, the portion(s) of the network updater 15 that reside on the secure memory shall occupy less than half a size of the secure memory, owing to memory constraints. Ideally though, both parts of the network updater 15 shall occupy as little memory as possible. For instance, some implementations of the network updater 15 have been successfully tested which use less then 64 ko for each part.

The connection interface 12 of the device 10 may for instance be of the following type: -Universal Serial Bus or USB; -External Small Computer System Interface or SCSI; -External Serial Advanced Technology Attachment or SATA; -Firewire; or -Thunderbolt.

More generally though, this could be any culTent or future connector that allows the computer to boot from the external device 10. lii addition, the same interface 12 can furthermore allow the user trusted device for communicating with any external device such as a beamer, a printer, or any other output device.

As usual, the user trusted device 10 may be provided with processing means (or computing means, i.e., CPU) 11, such as a crypto Processor, coupled to a memory, which more generally comprises both a persistent memory 14 and a non-persistent memory (not shown).

In the present context, the persistent memory notably stores computerized methods, e.g., components 15, 16 evoked above, to be executed by the processing means 11.

If necessary, the secure device has a card reader to read user credentials stored on a memory card, e.g., the non-secure memory 142 or any smart card. Suitable use can safely be made out of such data, e.g., user credentials as stored on the card. lii particular, a trustworthy connection can be established between a user (or strictly speaking the device 10) and a third party, e.g., a server, via the terminal and using such data. In a variant, the user credentials may be stored directly on the secure device. Further interfaces (like control buttons and display) may be provided to allow for interaction with the user.

The above embodiments have been succinctly described in reference to the accompanying drawings and may accommodate a number of variants. Several combinations of the above features may be contemplated. Examples are given in the next section.

2. Specific embodiments/Technical implementation details A specific embodiment is discussed now, which combine several optional features discussed in the previous section. This embodiment is again described in reference to FIG. 4: -Step SI, a secure device 10, a PC 101 and a network 165 are provided; -Step S2, the secure device 10 is connected to the PC 101, the PC is restarted; -Step S3: the boot loader 16 of the device 10 is detected by the BIOS 122 of the PC 101; -Step 53a: the PC 101 boots from the secure device 10; -Step S4, the network updater 15 is transferred to a memoiy of the PC 101, whereby o Step S5, the updater 15 executes at the PC 101; and o Step S6, interacts with the BIOS 122 to o Step 57a: initialize the network adapter 124 of the PC (), in order to o Step S7b: initiate a communication over the network 165, whereby the server is contacted, through the PC's network adapter. The server to contact is determined by the updater 15; -Steps SSa -58d, data are transferred back to the device 10, starting with connection data such that an end-to-end connection between the server 30 and the device 1 0 be established. Meanwhile, the updater is still active, forwarding data to the server on behalf of the device 10 and to the secunty device on behalf of the server. The following authentication scheme can for instance be implemented: o Authenticate server and possibly the client, e.g., by performing a handshake; o Determine new device firmware, or software update, which may be determined by a server administrator or by letting the user decide either on the PC through the updater or on the security device through some I/O mechanism of the security device; -Step S8d, the transfer of the update from the server to the client is completed and the update is stored on a memory (persistent or not) of the device 10; -At this point, another update could be initiated (which amounts to go back to step S7 or even 56 if the update is to be performed from a different server), else the connection is closed; -Next, step S9, the security device unpacks the data it has received and depending on how it was transferred (SSL. clear. etc.) it performs an integrity check. The device copies the unpacked data into (non-vo'atile) memory that can be securely controlled by the device software of the secure device 10 (e.g., firmware thereof), whereby an update is performed at the device 10; o Note that step S9 may actually be carried out in parallel to initiating another update or while this other update is being transferred into the device, provided that appropriate rollback mechanisms are in place. Although current user trusted devices do typically not have enough computing power to do this in parallel, s&utions are currently being tested which a'low for such a functionality; o Additionally, the device may reboot at various stages after the update has been downloaded. If the device reboots, the downloaded data may have to be verified again if stored on non-secure memory.

Note that Step S9 may be performed any time after the update is received. If the transfer is not complete, the firmware update may not be complete and may have to be restarted. The device may reboot at various steps, i.e., at any point during the update (at the device), to ensure a clean state (e.g., after the new firmware has been received and if the buffer-memory is non-volatile across reboots). Once the update has been received the computer may still be necessary, i.e., to provide power to the security device (if the latter is not self powered), or not, i.e., if the security device has its own battery.

In addition, instead of using the network functionality of the PC 101, other components of the computer 101 (providing storage) could be used as well to provide a firmware update (although less practical).

Also note that, in principle, interaction with the BIOS could be omitted if the device is capable of bringing its own network device driver (this would not be according to this invention). Yet, in this case only those computers equipped with a network card for which a device driver is present on the security device could be used for updating the device, which The device is connected to the PC through any connection facility that allows the PC to be booted from said device. Depending on the connector chosen, a smaller or wider range of computers may be useful (e.g., USB, tirewire, eSATA, etc.).

As touched earlier, different applications can be contemplated: Of primary interest are security devices like banking devices, secure boot, or secure storage devices, etc. Of especial interest are devices from which a host computer is to be, or likely to be booted anyways, for instance, to create a secure computing environment. However, a wider class of devices could be updated through the same mechanism, in which case security mechanisms such as handshake, integrity verification, etc., may possibly be omitted.

While the present invention has been described with reference to a Umited number of embodiments, variants and the accompanying drawings, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In particular, a feature (device-like or method-like) recited in a given embodiment, variant or shown in a drawing may be combined with or replace another feature in another embodiment, variant or drawing, without departing from the scope of the present invention, Various combinations of the features described in respect of any of the above embodiments or variants may accordingly be contemplated, that remain within the scope of the appended claims. In addition, many minor modifications may be made to adapt a particular situation to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims. In addition, many variants not explicitly touched above can be contemplated. For example, the secure device could be powered with solar cells or any other suitable batteries, etc. Furthermore, the computerized methods described herein have been categorized according to their main functions: enabling a computer 101 to start booting from the external device 10; and initiate a communication over the network. These main functions have been descnbed as being assigned to respective modules 15, 16, for the sake of clarity of the description. However, embodiments of the present invention could be equivalently described with the same functions distributed over one or more modules, each provided with different ones of these functions. For example, the boot enabling data structure 16 and the network updater 15 could be regarded as a single module, possibly referred to as a bootloader", while still performing the same functions as otherwise described herein.

REFERENCE LIST

Secure Device 11 Secure Device's CPU 12 Connection Interface 13 Encryption Data 14 Persistent Memory I 5 Network Updater 151 First Part Of The Network Updater 152 Second Part Of The Network Updater 16 Boot Enabling Data Structure (Boot Loader) Server General Computerized System 101 Host Computer (PC) 105 Processor Memory 111 Operating System (Os) Memory Controller 122 Firmware (BIOS) Of The Host Computer 124 Network Card Display Controller Display 141 Secure Memoiy 142 Non-Secure Memory 145 I/O Devices (Or Peripherals) Keyboard Mouse Network

Claims (15)

1. CLAIMS1. A user trusted device (10), comprising: a connection interface (12) enabling connection (S2) with a host computer (101); and a persistent memory (14) storing a boot enabling data structure (16) and a network updater (15), wherein, the network updater (15) is configured to interact, upon execution at a host computer (101). with a firmware (122) of the host computer to initiate a communication over a network (165) to which the host computer is connectable; and the boot enabling data structure (16): is detectable by the firmware (122) upon connection of the user trusted device (10) with said host computer (101); is such that the host computer (101) can boot from the user trusted device (10), preferably as per the data structure of the boot enabling data structure; and comprises instructions for the firmware (122) to initiate a transfer of said network updater (15) on the host computer (101) for subsequent execution at the host computer (101), upon the host computer booting from the user trusted device.
2. 2. The user trusted device (10) of claim 1. wherein said network updater is configured to interact, upon execution at said host computer, with said firmware (122) of the host computer to subsequently interact with a network card (124) of the host computer (101), in order to initiate said communication over the network as enabled by said network card (124).
3. 3. The user trusted device (10) of claim 1 or 2, wherein the network updater (15) comprises a reference to a server (30) to be contacted upon initiating said communication over the network.
4. 4. The user trusted device (10) of claim 1. 2 or 3, wherein said user trusted device comprises no network card.
5. 5. The user trusted device (10) of any one of claims 1 to 4, wherein said persistent memory compnses a secure memory (141), onto which is stored a first part (151) of the network updater (15); and a non-secure memory (142), onto which is stored a second part (152) of the network updater (15).
6. 6. The user trusted device (10) of claim 5. wherein the second part of the network updater (15) resides encrypted on the non-secure memory, a corresponding encryption key (13) being stored on the secure memory.
7. 7. The user trusted device (10) of claim 5 or 6, wherein the second pail of the network updater (15) occupies less than half a size of the secure memory, said memory size preferably less than or equal to 256 ko, more preferably less than or equal to 128 ko.
8. 8. The user trusted device (10) of any one of claims 1 to 7, wherein said network updater is configured to interact, upon execution at a host computer, with a firmware (122) of the host computer to initiate said communication, said firmware (122) being one of the following: BIOS, preferably with a PXE BIOS; Extensible Firmware hiterface (EFI) BIOS; or Unified Extensible Firmware hiteiface (UEFI) BIOS.
9. 9. The user trusted device (10) of any one of claims I to 8. wherein said connection interface (12) is of one of the foflowing types: Universal Serial Bus or USB; External Small Computer System Interface or SCSI; External Serial Advanced Technology Attachment or SATA; Firewire; or Thunderbolt.
10. 10. A system (1) comprising: a user trusted device (10) according to any one of the previous claims; a server (30) to be contacted upon initiating communication over the network, the network updater (15) of the user trusted device (10) comprising a reference to said server (3W; and preferably, said host computer (101).
11. II. A method for initiating communication between a user trusted device (10) according to any one of claims 1 to 9 and a network, the user trusted device (10) connectable to a host computer (101), said host computer connectable to said network, the method comprising: letting the boot enabling data structure of the user trusted device (10) be detected (S3) by the firmware (122) of the host computer (101), in order to make the host computer (101) boot (S3a) from the user trusted device (10), for subsequently transferring (S4) the network updater (15) at the host computer (101), such as for the network updater (15) to execute (S5) at the host computer (101) and interact (S6) with the firmware to initiate (S7, S7a, S7b) a communication over said network.
12. 12. The method of claim 11, further comprising: causing said network updater (15) to interact (S6) with said firmware of the host computer to subsequently interact (S7a) with a network card of the host computer (10 I), in order to initiate (S7b) said communication over the network as enabled by said network card.
13. 13. The method of claim 11 or 12, further comprising contacting (S7c) a server (30) referenced by the network updater (15), upon initiating said communication over the network.
14. 14. The method of claim 13, further comprising transferring (S8. S8a -S8d) data, preferaHy a user trusted device (10) firmware update, from the server (30) to the user trusted device (1W; storing (SSd) said transferred data on a memory (14), preferably a persistent memory, of the user trusted device (1W; and preferably, updating (S9) software of the user trusted device (10) according to the transferred data as stored on the memory of the user trusted device (10).
15. 15. A computer program product for initiating communication between a user trusted device (10) and a network (165), the computer program product comprising a computer-readable storage medium having a boot enabling data structure (16) and a network updater (15) embodied therewith, wherein, the network updater (15) is configured to interact, upon execution at a host computer (101), with a firmware (122) of the host computer to initiate (S7) a communication over a network (165) to which the host computer is connectable; and the boot enabling data structure (16): is detectable by the firmware (122) upon connection of the user trusted device (10) with said host computer (101); is such that host computer (101) can boot from the user trusted device (10), preferably as per the data structure of the boot enabling data structure; and comprises instructions for the firmware (122) to initiate a transfer of said network updater (15) on the host computer (101) for subsequent execution at the host computer (101), upon the host computer booting from the user trusted device.