WO2014076452A1 - Dispositif informatique sécurisé et procédé associé - Google Patents

Dispositif informatique sécurisé et procédé associé Download PDF

Info

Publication number
WO2014076452A1
WO2014076452A1 PCT/GB2013/052824 GB2013052824W WO2014076452A1 WO 2014076452 A1 WO2014076452 A1 WO 2014076452A1 GB 2013052824 W GB2013052824 W GB 2013052824W WO 2014076452 A1 WO2014076452 A1 WO 2014076452A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
cellular network
software components
electronic device
version
Prior art date
Application number
PCT/GB2013/052824
Other languages
English (en)
Inventor
Michael Naggar
Ashutosh Sureka
Shuchi Patel
Sunil GATTU
Bacchababu GUPTA
Original Assignee
Barclays Bank Plc
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
Priority claimed from GB1220776.7A external-priority patent/GB2507596B/en
Application filed by Barclays Bank Plc filed Critical Barclays Bank Plc
Priority to EP13808169.0A priority Critical patent/EP2920751A1/fr
Publication of WO2014076452A1 publication Critical patent/WO2014076452A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/353—Payments by cards read by M-devices

Definitions

  • This invention relates to secure data storage, access and communication, and more particularly to a system, device and method for maintaining software applications in a secure computing environment.
  • USB Universal Serial Bus
  • TM IronKey
  • RTM Imation
  • Option CloudKey Kobil mIDentity
  • TM IronKey
  • RTM Imation
  • Option CloudKey Kobil mIDentity
  • the USB device itself is adapted to provide secure authentication to the associated service and data encryption.
  • the USB devices in known environments rely at least in part on use of the host computer for processing and communication of data for a transaction. Therefore, known computing environments are susceptible to security breaches, for example from malicious software or hardware resident on the host computer.
  • a computer-implemented method for maintaining software components in a portable electronic device including memory means storing software components executable from the device, data interface means for coupling the device to a host computer, contactless interface means for receiving payment token data from a contactless payment token, and cellular network interface means for communication of data over a cellular network, the method comprising initiating an upgrade process when the device is coupled to the host computer and receiving data including a different version of at least one of said software components; installing the received version of the at least one software component; and executing the installed software components to initiate a payment transaction with a remote system. Payment token data is received via the contactless interface means and transmitted to the remote system.
  • a computer-implemented method for maintaining software components in a portable electronic device including memory means storing software components executable from the device from an active partition, data interface means for coupling the device to a host computer, contactless interface means for receiving payment token data from a contactless payment token, and cellular network interface means for communication of data over a cellular network, the method comprising providing an associated pair of first and second logical storage partitions for storing different versions of a software component, wherein the first partition is configured as the active partition storing a current version of the software component; receiving and storing data including a new version of the software component in the second partition; and configuring the second partition to be the active partition.
  • the received version of the at least one software component is installed into an inactive partition, and switched with an active partition storing a previous version of the at least one software component.
  • the software components may include one or more of a boot loader, a root file system, a kernel, a browser application, an application user interface and an Secure Socket Layer (SSL) certificate.
  • SSL Secure Socket Layer
  • the device establishes a secure connection with a remote mobile gateway over the cellular data network, and receives data including a new version of a software component over the cellular network via the cellular network interface means.
  • the upgrade process includes determining one or more software components in the device that can be updated with a new version stored on a remote upgrade server, by comparing a local policy data file stored on the device with a remote policy data file received from the remote upgrade server.
  • the application software further configures the portable electronic device to establish a secure connection with a remote mobile gateway over the cellular data network.
  • the data interface means comprises a Universal Serial Bus (USB) data interface
  • the memory means comprises a non-volatile flash memory
  • the contactless payment token is a Near Field Communication (NFC) capable payment card or mobile device.
  • NFC Near Field Communication
  • the software components include a web browser for displaying an application interface including a web form for initiating the payment transaction, and the application software further configures the portable electronic device to automatically populate the web form with the received payment token data.
  • a portable electronic storage device comprising means for performing the methods as described above.
  • an associated computer program arranged to configure a system or device to carry out the above methods.
  • Figure 1 is a block diagram showing the main components of a secure computing environment.
  • Figure 2 is a block diagram showing the main components of an electronic device in the secure computing environment of Figure 1 according to an embodiment of the invention.
  • Figure 3 is a block diagram schematically illustrating an example of pairs of active-inactive logical storage partitions according to an embodiment of the invention.
  • Figure 4 which comprises Figures 4A and 4B, is a flow diagram illustrating the main processing steps performed by components of the computing environment of Figure 1 according to a first embodiment.
  • Figure 5 is a flow diagram illustrating the main processing steps performed by components of the computing environment of Figure 1 for an example of a device and user authorisation process after boot up of the electronic device.
  • Portable USB flash memory devices that store and run software applications completely within the device itself are a way of providing highly secure control and access to online services in a secure computing environment, without using the network connection of the host computer to which the USB device is connected.
  • the USB device provides secure access to a user's financial account data and account services provided by an online banking backend system, via custom browser software securely stored on the device that is automatically loaded and executed when the USB device is connected to a host computer, to render the custom browser user interface (Ul) for display to the user.
  • Ul custom browser user interface
  • a secure computing environment 1 is made up of a number of components: the portable electronic device 3, the host computer 5 and the backend system 7.
  • the electronic device 3 is a secure and self-contained device with a USB serial communication module 21 for connecting the device to a USB interface 5a of the host computer 5.
  • the electronic device 3 also includes an on-board cellular data modem 23 for secure network access to services provided by a backend system 7, via a direct and authenticated connection to a mobile gateway 8 of the backend system 7 over a cellular network 9.
  • the backend system 7 may be a computer server providing APIs to customer banking functionalities such as looking up account balance, making payments, making transfers, etc.
  • the mobile gateway 8 is of a type that is known per se in mobile telephony networks and need not be described further.
  • the backend system 7 includes an upgrade server component 10 storing data files for the upgrade process in an application server database 12.
  • the data files for the upgrade process include install packages containing code for the software components, such as application program code 26, that can be installed onto the electronic device 3.
  • the upgrade server 10 can be provided as a separate or distributed component, in secure communication with the backend system 7, over the data network 11 for example.
  • the upgrade process of the present embodiments uses policy data files 20 to keep track of software versions, both currently installed and the latest available.
  • the electronic device 3 stores local policy data files 20a that include data describing the currently installed software components and the associated version identifiers.
  • the upgrade server 10 stores remote policy data files 20b that includes data describing the latest available software components and the associated version identifiers.
  • Each policy data file 20 may include data associated with one or more respective software component.
  • a single remote policy data file 20 is provided for a particular software update release, including data identifying the latest versions for each of the associated software components of that release.
  • the policy data files 20 are based on the standard .INI file format and specify the following for each software component: component name, latest available version, install package size (used to verify the file after download) and package signature (used to verify the digital signature of the package).
  • the policy data files 20 may further include an overall release version number and a mandatory/optional data field indicating whether the overall release is mandatory or optional.
  • the mandatory/optional data field can be used to provide the user with the option to skip specific component(s) during the upgrade process.
  • the policy data files 20 may also include a data field identifying the last mandatory version for an associated software component, which is useful when a user is going through an upgrade process after missing a number of incremental updates over a period of time.
  • a user may currently have an old version #2 of the browser application 28 installed on the electronic device 3.
  • the latest software component update release includes a much newer version #6 of the browser application 28, but the remote policy data file 20b indicates that this is an optional upgrade.
  • the last mandatory version for the browser application 28 can be indicated as version #5.
  • version #6 is an optional update
  • the electronic device 3 has not yet been upgraded with the mandatory version #5, which would be the minimum version required for upgrade
  • the browser application 28 component will be treated as requiring a mandatory upgrade to at least the latest mandatory version.
  • the browser application 28 component can be upgraded directly to the latest available version, or the electronic device 3 can prompt the user for their preference and selection, via the host computer 5.
  • the USB serial communication module 21 provides a link between custom browser software 28 and security and network stacks 32 on the electronic device 3, in order to translate and transmit HTTP/HTTPS requests from the custom browser 28 running on the electronic device 3 via the host computer 5 over the serial USB interfaces 5a, 21 and to return the responses back to the browser.
  • this USB serial communication module 21 can also include a set of interfaces that allow the custom browser 28 access to custom functions on the electronic device 3.
  • the cellular network 9 may be any suitable cellular data communication network such as GPRS, EDGE, 3G, LTE, 4G, for example.
  • the host computer 5, which can be a personal computer, portable laptop, tablet PC, or the like, typically communicates data over a data network 11 via a communication interface 5b.
  • the host computer 5 may also include components included in commonly known computing devices, such as a processor, a display, user input devices and controllers, etc., which are not shown for clarity.
  • the data network 11 may be any suitable data communication network such as a wireless network, a local- or wide-area network including a corporate intranet or the I nternet, using for example the TCP/IP protocol. Such communication protocols are of a type that are known per se in data networks and need not be described further.
  • the USB device 3 also includes circuitry and logic to enable contactless payment transactions.
  • a Near Field Communication (NFC) module 25 is provided to communicate data with an N FC capable payment token 12, such as an N FC payment card or NFC capable mobile device with integrated payment software and/or hardware as are known in the art.
  • NFC Near Field Communication
  • Components of the host computer 5 can also be in communication with a merchant system 13, which could be for example a merchant's Point of Sale (POS) back-end system or an online merchant's website server system, as well as merchant acquirer 14a, payment scheme 14b and card issuer 14c components over the data network 11, which are typically provided for authorizing and settling payment transactions with the merchant system 13, and need not be described further.
  • POS Point of Sale
  • the user plugs the electronic device 3 into the host computer 5 to automatically initiate a boot up process on the electronic device 3, before loading and launching application program code 26 stored on the electronic device 3.
  • the application program code 26 includes an application Ul 30, that can be built in HTML5 for example, and a custom browser application 28 that is used to render the application Ul 30 to the user on the host computer 5.
  • the browser application 28 is customized to restrict use for only the device application Ul 30.
  • the browser application 28 is coupled to the USB Serial communication module 21 to make HTTP requests and receive responses via the electronic device 3 rather than directly using the host computer's network interface 5b.
  • an electronic device 3 includes the USB interface 21 and modem 23, as discussed above, that are coupled to a processor 27.
  • the electronic device 3 also includes a Subscriber Identity Module (SIM) 29 coupled to the modem 23, and an NFC module 25 and associated antenna.
  • SIM Subscriber Identity Module
  • the processor 27 may be any type of processor, including but not limited to a general-purpose digital signal processor or a special purpose processor.
  • the processor 27 may include on-chip memory 31, for example Static Random Access Memory (SRAM) 33 and Read Only Memory (ROM) 35.
  • SRAM Static Random Access Memory
  • ROM Read Only Memory
  • the processor 27 is also coupled for access to volatile Random Access Memory (RAM) 37 and non-volatile memory 39 of the electronic device 3, for example via a data bus (not illustrated for clarity).
  • the non-volatile memory 39 stores code for the various software components installed on the electronic device 3, including boot loader and kernel code 41, operating system (OS) code and firmware 43, code for the security and network stacks 32, and code for application programs 26, including the custom browser application 28 and the application Ul 30.
  • the processor 27 runs the boot loader code 41 upon power up of the electronic device 3, to load the OS code 45, the security and network stacks 32 and the application program code 26 into RAM 37 for subsequent execution by the processor 27.
  • the network and security stacks 32 include a cryptographic library that provides encryption and decryption functionality for data communicated to and from the electronic device 3.
  • Local policy files 20a are also stored in the non-volatile memory 39 to identify the currently installed software components and the associated version identifiers.
  • Electronic device 3 is configured to route data traffic via the host computer 5, or via the onboard cellular data modem 23.
  • the security stack consists of all the components necessary to ensure secure access to the electronic device 3, including device authorization, user authentication and network traffic encryption.
  • the USB serial communication module 21 integrates with the security stack to apply the necessary encryption and headers to the requests it receives from the browser application 28.
  • the network stack consists of all the components necessary to make HTTP and HTTPS requests over the cellular network 9 and the data network 11.
  • the USB serial communication module 21 also integrates with the network stack to submit the requests it receives from the browser application 28.
  • the electronic device 3 is configured with logic to perform routing of requests based on predetermined factors, such as signal strength, bandwidth speed, network data charges, etc. For example, the electronic device 3 can determine connection availability and connection speed over the cellular network 9 and if the cellular data signal is found to be weak or unavailable, the network stack may route the request via the network interface 5b of the host computer 5.
  • the non-volatile memory 39 consists of one or more flash memory components, although other forms of non-volatile memory may be suitable.
  • the non-volatile memory 39 is divided into logical storage partitions 40, including one or more pairs of partitions. For each pair of partitions, an active partition 40A stores an existing version of one or more software components and an associated inactive partition 40B stores a backup or new version of the respective software components.
  • Figure 3 is a schematic illustration of an exemplary set of active-inactive pairs of logical storage partitions 40.
  • the non-volatile memory 39 includes a first active partition 40A-1 storing a current version of application program code 26, a second active partition 40A-2 storing a current version of boot loader and kernel code 41, and a third active partition 40A-3 storing a current version of operating system code 43, which may include root file system code.
  • a respective inactive partition 40B associated with each active partition 40A including a first inactive partition 40B-1 for storing a backup or new version of application program code 26, a second inactive partition 40B-2 for storing a backup or new version of boot loader and kernel code 41, and a third inactive partition 40B-3 for storing a backup or new version of operating system code 43 and/or root file system code.
  • an archive partition 40-4 is also provided for storing data received from the upgrade server 10 and used by the upgrade process.
  • one or more additional partitions 40-n may be provided, such as, a user data partition for storing non-secured user data used by the software components, a log partition for storing all application and system log files, and one or more further spare partitions for storing future applications and data.
  • the data stored in the partitions can be secured, for example by encryption.
  • further partition pairs may be provided to store different versions of application program code 26 adapted to run on respective operating systems of different host computers and with different file system architectures and partition types (e.g. FAT, FAT32, NTFS, HFS+, etc.).
  • the electronic device 3 includes a protected storage chip 51 coupled to the processor 27, with a dedicated microcontroller (or microprocessor) 53 for executing protection program code 55 that controls access to encryption key data 57 stored in protected non-volatile memory 59 on the storage chip 51, as described in the Applicant's co-pending application entitled "Device and Method for Secure Memory Access".
  • the protection program code 55 controls access to the protected non-volatile memory 57 by making the stored encryption key data 61 available only during a pre- defined time window, for example within a pre-defined number of clock cycles once the electronic device 3 is powered on.
  • the loading of the encryption key data 61 can be carried out as one of the initial steps in a boot loading (or bootstrapping) process and prior to initiating and accepting any external comm unications to the electronic device 3.
  • the loaded encryption keys 61 are then available for subsequent use by the processor, for example when executing the OS code 43 and the application program code 45 to authenticate a user of the electronic device 3 and to handle service requests to and from the backend system 7.
  • Such key based encryption and decryption techniques are of a type that are known per se in data cryptography and need not be described further.
  • the processor 27 in the boot loader mode executes the remaining instructions to continue normal loading of the boot OS code and initialisation of the external communication interfaces, such as the USB interface 21 and the modem 23.
  • the N FC module 25 may include circuitry and logic to provide secured encryption and decryption of data for the electronic device 3, in addition to contactless payment functionality.
  • the encryption key data 57 may instead be stored in a protected non-volatile memory or secure element of the NFC module 25, along with one or more applets or modules that provide the encryption/decryption functionality. In this way, the encryption keys are not communicated from the secure element of the N FC module 25.
  • the electronic device 3 can be further adapted to include circuitry and logic to provide a defence against subversion of hardware attacks, such as voltage tam pering, etc.
  • step S4- 1 the user plugs the electronic device 3 into the host computer 5 to automatically initiate the boot loader code 41 stored on the electronic device 3.
  • the boot loader code 41 is executed by the electronic device 3 to (perform hardware and software checks and prepare the kernel and operating system for startup).
  • the boot process may include loading of encryption keys from the protected non-volatile memory 57, as described in the applicant's co-pending application GB1219514.5.
  • the boot loader code 41 includes instructions to check if any of the software components stored in the electronic device 3 can be updated to a newer version.
  • the electronic device 3 can select one of the available communication paths based on predetermined factors, such as signal strength, bandwidth speed, network data charges, etc. Accordingly, at step S4-3, the electronic device 3 selects one of a data connection over the cellular network 9 or a data connection over the data network 11 via the host computer 5.
  • the electronic device 3 establishes a secure connection with the upgrade server 10 over the selected connection.
  • the electronic device 3 selects the data connection over the cellular network 9, and performs a two-way authentication with the backend system 7 via the mobile gateway 8 for a secured connection.
  • the electronic device 3 requests a remote policy data file 20b from the upgrade server 10 using the chosen secured data communication route.
  • the upgrade server 10 retrieves and transmits a stored remote policy data file 20b to the electronic device 3 at step S4-9.
  • the remote policy data file 20b is encrypted by the upgrade server 10 for transmission to the electronic device 3.
  • the received remote policy data file 20b may be stored in RAM 37 and is processed by the electronic device 3 at step S4-11 to compare the version numbers of the latest available versions of software components stored in the application server database 12 with the version numbers in the local policy data file 20b of the electronic device 3.
  • the electronic device 3 identifies any software components that can be upgraded with newer versions from the application server database 12.
  • the archive partition 40-4 is used to store a downloaded copy of the data files for the upgrade process. Accordingly, at step S4-15, the archive partition 40-4 is mounted to the root file system. It will be appreciated that the downloaded files for the upgrade process may instead be stored in a temporary memory of the electronic device 3.
  • the electronic device 3 requests update files for the identified software components that can be updated, such as the install packages stored in the application server database 12.
  • the electronic device 3 may request additional detailed information about an available newer version of a software component, and may enable user selection of the components that are to be updated.
  • the upgrade server 10 transmits the requested update files from the application server database 12 to the electronic device 3.
  • the update file or files for each identified software component are compressed into a single install package data file for transmission to the electronic device 3.
  • the electronic device 3 stores the received update files in the mounted archive partition 40-4, at step S4-21.
  • the electronic device 3 proceeds to install the upgraded version of each identified software component from the archive partition 40-4 into the respective inactive partition 40B associated with the software component.
  • updated browser application code 28 and updated application Ul code 30 can be stored in the first inactive partition 40B-1
  • updated boot loader and kernel code 41 can be stored in the second inactive partition 40B-2
  • updated operating system code 43 and root file system files can be stored in the third inactive partition 40B-3.
  • the electronic device 3 makes the inactive partition 40B for that software component the active partition, at step S4-25.
  • the previously active partition 40A is made inactive, to effectively and efficiently switch the pair of partitions 40 for the updated software component.
  • the new inactive partition 40B stores a copy of the older version of the software component as a backup or for subsequent rollback.
  • the electronic device 3 can store data identifying which ones of the partitions 40 are active, for example as respective pointers to the active partitions 40A and/or as an active partition table.
  • a special case to note is when two or more software components of the electronic device 3 are stored on the same partition.
  • the browser application 28 and corresponding HTML-based application Ul 30 reside on the same partition 40A. If both components are being upgraded in the same update release, then there is no special handling needed. However, when only one of the components (e.g. the browser application 28) is being upgraded by an update release, the current version of the other component (e.g. the application Ul 30) is copied from the active partition 40A-1 to the inactive partition 40B-1. Then the new version of the first component is upgraded by installing the received install package to the inactive partition 40B-1, before the pair of active-inactive partitions 40-1 are swapped.
  • each software component could be separated and stored in respective distinct partitions, to simply the upgrade process.
  • this alternative arrangement can result in a significantly large number of partitions, with detrimental impact on the efficiency of the system.
  • step S4-27 the electronic device 3 determines if any more software components are to be upgraded, and steps S4-23 and S4-25 are repeated to upgrade the remaining software components. After all the updates for the identified software components have been installed, the electronic device 3 is rebooted at step S4-29.
  • the electronic device 3 of the present embodiments provides the ability to remotely manage software and firmware upgrades of as many components as possible so the devices can be upgraded in the field, while maintaining software package security. Additionally, flexibility is provided by the ability to upgrade various components or software sub-systems independently, and by the ability to efficiently rollback to previous versions or releases by swapping the active-inactive pair of partitions when needed.
  • the electronic device 3 proceeds to load and launch application program code 26 stored on the electronic device 3, at step S5-1.
  • the custom browser application 28 is launched and used to render and display the application Ul 30 to the user in the host computer 5 environment.
  • the user can interact with the Ul 30 being displayed in the browser 28, for example by clicking a link or a button to select one or more functions or services that requires communication with the mobile gateway 8 of the backend system 7.
  • the browser application 28 sends a data request to a serial communication handler (not illustrated) on the host computer 5, responsible for interfacing with the USB serial communication module 21 of the electronic device 3.
  • the serial communication handler sends the data requests to a serial listener 22 of the USB module 21, for example via a USB serial driver installed on the host computer 5.
  • step S5-3 the processor 27 of the electronic device 3 requests a secure connection to the mobile gateway 8 of the backend system 7 over the cellular network 9, before user requests can be securely communicated with the backend system 7. Accordingly, at step S5-5, authentication and authorisation of the electronic device 3 is processed, by authorising and verifying communication with the mobile gateway 8. The requests are encrypted by the security stack 28 using the encryption keys 61 loaded into the SRAM 33 during the secure boot loading process described above.
  • the serial listener 22 of the USB module 21 sends the data request to the cryptography library of the network and security stack 32, to encrypt the data request using the encryption keys 61.
  • the serial listener 22 submits the request to the network stack 32, which first checks if good cellular signal strength is available via the cellular data modem 23. If a strong cellular signal is detected, the data request is sent to the mobile gateway 8 over the cellular network 9. Otherwise, the request can be submitted using the host computer 5 network interface 5b over the data network 11.
  • the routing decision can instead or additionally be based on other predetermined cellular network-related factors, such as bandwidth speed, network data charges, etc.
  • the request is sent over the cellular network 9
  • the data request is converted into an encrypted HTTPS request using an Open SSL Library and passed to the cellular data modem 23, which transmits the request to the mobile gateway 8.
  • the serial listener 22 sends the request to the host computer 5 via the USB serial interface 5a.
  • the HTTPS request is sent by the host computer 5 to the mobile gateway 8 over the data network 11 (e.g. the Internet) via the network interface 5b.
  • the mobile gateway 8 authorises and verifies communication with the electronic device 3, in a corresponding manner.
  • the electronic device 3 processes authentication of the user after the electronic device 3 has been authenticated.
  • the electronic device 3 prompts the user for authentication.
  • User authentication can take one or more of any known forms, for example by prompting the user to input a pre-registered passcode via the application Ul 30 and browser application 28, or via additional communication interfaces (not shown) that are made available on the device, such as a thumbprint scanner, dials or buttons to select passcode digits, et.
  • the host computer 5 receives user input of a passcode via the application Ul 30.
  • the user input passcode is verified by the electronic device 3 against a stored pre-registered passcode in order to authenticate the user at step S5-13.
  • authentication of the user is securely communicated to the mobile gateway 8, which verifies that the user is valid for example by comparing received details with stored records for the user.
  • the electronic device 3 receives confirmation from the mobile gateway 8 that the user is authorised.
  • the browser application 28 and application Ul 30 display confirmation to the user and proceed with normal user operation at step S5-19, for example by displaying to the user a secure web home page for the services provided by a backend system 7.
  • the electronic device 3 is configured to determine that an installed version of the kernel is stable before that version can be stored as a backup version, as described in the upgrade process above.
  • the electronic device 3 stores and maintains a persistent counter, for example in non-volatile memory 39, to count the number of successful boots with that installed kernel version.
  • the counter is incremented by the electronic device 3 every time the installed kernel is successfully used to boot the electronic device 3. When the counter reaches a threshold, that version of the kernel is deemed as a stable version.
  • the counter is checked to determine whether the currently installed version can be used as a new backup copy. If the kernel is determined to be stable because of a predetermined number of successful boots, the installed version of the kernel code 41 can be used as a new backup copy. In this embodiment, a back up copy of the current installed kernel is first stored on the inactive partition 40B-2 and the new version of the kernel is installed directly on the active partition 40A-2. On the other hand, if the current installed version of the kernel has proven to be unstable for any reason, the counter will be under the threshold because that version of the kernel has not been used enough times to know if it is stable. In this case, the kernel code 41 backup step is skipped. As a result, a previously known stable kernel as stored in the inactive partition 40B-2 would continue to be available as a backup copy should a rollback be necessary.
  • the electronic device 3 can attempt to boot from the inactive kernel partition 40B-2. If this is successful, the electronic device 3 will swap the active/inactive kernel partitions 40-2.
  • the electronic device 3 can also store data identifying that the now inactive kernel partition 40B-2 is known to contain a bad kernel image, in order to prevent another rollback that would otherwise cause that partition 40B-2 with the unstable version of the kernel code to again become active.
  • the electronic device 3 is configured to allow a user to continue using the electronic device 3 while the upgrade is in progress. This is achieved by facilitating download of the requested update files for the upgradeable software components as a background operation by the operating system of the electronic device 3.
  • a problem arises because the user may be unaware this an upgrade process is happening, and it is possible that the user disconnects the electronic device 3 from the host computer 5 in the middle of a download, thus disconnecting the power supply to the electronic device 3, as well as a tethered data connection via the host computer 5 if in use.
  • the above identified problem is addressed by providing a resume capability in the upgrade process.
  • the electronic device 3 will again check for available upgrades on the upgrade server 10. Since the upgrade was not completed the last time, the electronic device 3 will still find upgradeable software components after comparing the received remote policy data file 20b with the local policy data file 20a. The electronic device 3 can then check what, if any, update files have already been downloaded for this update release by comparing the file size with the file sizes identified in the remote policy data file 20b. The electronic device 3 will skip the request for previously downloaded upgrade files that are already stored in the archive partition 40-4, and resume downloading the remaining update files as necessary.
  • Partially downloaded files can be managed via an appropriate download manager as is known in the art, with corresponding support from the upgrade server 10 to stream partially downloaded files.
  • the electronic device 3 can save an indicator that a new version is available for installation. The next time the electronic device 3 is plugged in, the user can be prompted to complete the installation of the downloaded updates. Alternatively, the user can be prompted to complete the installation during user logoff prior to disconnecting the electronic device 3, or at any other appropriate point by the application Ul 30.
  • the software upgrade process is initiated by the boot loader code that checks for software components of the electronic device that can be updated, effectively as part of the boot process.
  • the boot loader can instead be configured to fully boot the kernel and initiate one or more software application modules, such as the browser application.
  • the software application modules themselves can include the code to check for and perform the upgrade process, including requesting a remote policy document from the upgrade server for that particular module, identifying if the module can be updated and upgrading components of the module, as described in the embodiments above.
  • the portable electronic device is a USB flash memory storage device. It will be appreciated that the portable electronic device may be any device that is portable and used to store digital information. Additionally, the data communication interface between the portable device and a host computing device or platform may be any form of standard or proprietary computing interface, such as IEEE 1394 (Firewire (RTM)), SCSI, Thunderbolt, Lightning, etc.
  • the electronic device is powered by the host computer via the USB interfaces when connected.
  • the electronic device can include a battery and associated power charging circuitry, for powering the components of the device and enabling persistent storage of data in volatile memory if necessary.
  • the secure computing environment can trigger remote updates even when the electronic device is not plugged in.
  • the onboard battery will enable the processor on the electronic device to be powered up to perform the local operations described in the embodiments above, initiated by receiving a remote command from the upgrade server for example. This can happen in several exemplary ways. 1) Push: On a 3G-enabled electronic device, the command can be sent as an SMS message to the device over a closed network provided by the 3G carrier.
  • the upgrade process can be triggered to execute on the device using the power in the onboard battery, if charged. This capability is useful to carry out upgrades with no user intervention, particular advantageous for mandatory upgrades.
  • 2) Polling The electronic device can switch to a low power mode when not plugged in using the onboard battery. In this mode, only minimal number of processes and functionality are available. The device makes periodic requests to the upgrader server to check if new updates are available.
  • the cellular network 9 and the data network 11 are illustrated as separate networks. It will be appreciated that the data network itself can include communication links or paths over a cellular communication network such as GPRS, EDGE, 3G, 4G, LTE, for example, or a combination of such communication paths.
  • a cellular communication network such as GPRS, EDGE, 3G, 4G, LTE, for example, or a combination of such communication paths.
  • the encryption keys, passcodes and the software component version identifiers described above may take any respective form, and may be composed of numeric or alphabetic symbols, non-alphanumeric symbols, or a combination of such symbols.
  • the upgrade process described in the embodiments above can also be applied to any other type of software component stored on the electronic device in addition to the specific mentioned examples.
  • the upgradeable software components can also include independent components such as Secure Socket Layer (SSL) certificates needed to communicate with the backend system using SSL as well as public certificates for verifying the digital signatures of the install packages. This ability allows the secure computing environment to refresh the certificates by themselves when needed, for example, when current certificates expire and new ones are issued or when certain certificates have been revoked, etc.
  • SSL Secure Socket Layer
  • SSL Secure Socket Layer
  • This ability allows the secure computing environment to refresh the certificates by themselves when needed, for example, when current certificates expire and new ones are issued or when certain certificates have been revoked, etc.
  • Various software implementations are described in terms of the exemplary electronic device. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.
  • the computer programs (also called computer control logic) discussed in the embodiments above, when executed, enable the computer system of the electronic device to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of the computer system.
  • the software may be stored in a computer program product and loaded into the computer system using a removable storage drive, hard disk drive, or communication interface, to provide some examples.
  • the terms "computer program medium” and “computer usable medium” are used generally to refer to media such as removable storage drive, a hard disk installed in hard disk drive, and signals. These computer program products are means for providing software to computer system of the electronic device. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé et un dispositif d'entretien de composants de logiciel dans un dispositif électronique portable. Le dispositif comprend des composants de logiciel de stockage de mémoire exécutables à partir du dispositif, dotés de paires associées de partitions de stockage logiques permettant de stocker différentes versions des composants de logiciel, une interface de données permettant de coupler le dispositif à un ordinateur hôte, une interface sans contact permettant de recevoir des données de jeton de paiement d'un jeton de paiement sans contact, et une interface de réseau cellulaire pour une communication de données sur un réseau cellulaire. Un processus de mise à niveau est lancé lorsque le dispositif est couplé à l'ordinateur hôte. Des données incluant une version différente d'au moins l'un desdits composants de logiciel sont reçues, installées et exécutées pour lancer une transaction de paiement avec un système à distance. Des données de jeton de paiement sont reçues via les moyens d'interface sans contact et transmises au système à distance.
PCT/GB2013/052824 2012-11-19 2013-10-30 Dispositif informatique sécurisé et procédé associé WO2014076452A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP13808169.0A EP2920751A1 (fr) 2012-11-19 2013-10-30 Dispositif informatique sécurisé et procédé associé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1220776.7A GB2507596B (en) 2012-10-30 2012-11-19 Secure computing device and method
GB1220776.7 2012-11-19

Publications (1)

Publication Number Publication Date
WO2014076452A1 true WO2014076452A1 (fr) 2014-05-22

Family

ID=49780080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2013/052824 WO2014076452A1 (fr) 2012-11-19 2013-10-30 Dispositif informatique sécurisé et procédé associé

Country Status (2)

Country Link
EP (1) EP2920751A1 (fr)
WO (1) WO2014076452A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010032216A1 (fr) * 2008-09-19 2010-03-25 Logomotion, S.R.O. Systeme d'application de paiement electronique et procede d'autorisation de paiement
EP2458569A1 (fr) * 2010-11-24 2012-05-30 Kobil Systems GmbH Dispositif de support de données doté d'un processeur spécifique pour l'exécution d'un programme d'accès au réseau

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023620A (en) * 1997-02-26 2000-02-08 Telefonaktiebolaget Lm Ecrisson Method for downloading control software to a cellular telephone
US8181020B2 (en) * 2005-02-02 2012-05-15 Insyde Software Corp. System and method for securely storing firmware
EP1785902B1 (fr) * 2005-10-28 2010-05-05 Emma Mixed Signal C.V. Contrôle d'accès par table à clé de décryptage sur ASIC ou ASSP
SK50042008A3 (sk) * 2008-01-04 2009-09-07 Logomotion, S. R. O. Spôsob a systém autentifikácie najmä pri platbách, identifikátor totožnosti a/alebo súhlasu
TWI363298B (en) * 2008-02-29 2012-05-01 Hon Hai Prec Ind Co Ltd Communication device and firmware update method thereof
DE102008021567B4 (de) * 2008-04-30 2018-03-22 Globalfoundries Inc. Computersystem mit sicherem Hochlaufmechanismus auf der Grundlage einer Verschlüsselung mit symmetrischem Schlüssel
US10454693B2 (en) * 2009-09-30 2019-10-22 Visa International Service Association Mobile payment application architecture

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010032216A1 (fr) * 2008-09-19 2010-03-25 Logomotion, S.R.O. Systeme d'application de paiement electronique et procede d'autorisation de paiement
EP2458569A1 (fr) * 2010-11-24 2012-05-30 Kobil Systems GmbH Dispositif de support de données doté d'un processeur spécifique pour l'exécution d'un programme d'accès au réseau

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2920751A1 *

Also Published As

Publication number Publication date
EP2920751A1 (fr) 2015-09-23

Similar Documents

Publication Publication Date Title
US9916574B2 (en) Secure computing device and method
EP2915088B1 (fr) Dispositif et procédé d'accès sécurisé à une mémoire
EP2973187B1 (fr) Personnalisation de dispositif monotouche
TWI537765B (zh) 板上小型應用程式移轉
CN107408172B (zh) 从用户信任的设备安全地引导计算机
AU2015358292B2 (en) Computing systems and methods
WO2014068306A1 (fr) Environnement informatique sécurisé
EP2917828A1 (fr) Procédés pour offrir une protection anti-retour en arrière dans un dispositif ne comportant pas de mémoire non volatile interne
US10025575B2 (en) Method for installing security-relevant applications in a security element of a terminal
JP5296627B2 (ja) 端末保護システム及び端末保護方法
TWI581187B (zh) 傳送用以安裝作業系統之資料影像的技術
EP3807774B1 (fr) Provisionnement réseau et tokenisation à l'aide d'un terminal distant.
WO2014076452A1 (fr) Dispositif informatique sécurisé et procédé associé
US11409541B2 (en) Systems and methods for binding secondary operating system to platform basic input/output system
CN105556536A (zh) 一次性通电密码
CN110851881A (zh) 终端设备的安全检测方法及装置、电子设备及存储介质
CN103870302B (zh) 可网络更新的用户信任装置
US10846580B2 (en) IC chip support terminal, IC chip setting method, and program
JP2020013333A (ja) 端末装置、認証サーバ、本人確認管理システム、および、本人確認管理プログラム

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: 13808169

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2013808169

Country of ref document: EP