JP2016530802A - Encryption of raw sensor input for passcode input security - Google Patents

Abstract

A sensor input input encryption method for passcode input security is disclosed. The method in one embodiment includes presenting a passcode input interface on the electronic device for a user to input a passcode input. Next, the electronic device receives an input event indicating at least a portion of the passcode input by the user from a sensor of the electronic device. Subsequently, the electronic device encrypts the sensor value of the input event and transmits the encrypted sensor value over the network to an external system, thereby the path from the encrypted sensor value. Decode the code input. [Selection] Figure 1

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is a US patent application Ser. No. 14 / 055,838 filed Oct. 16, 2013 which claims the benefit of US Provisional Application No. 61 / 859,253, filed Jun. 28, 2013. All the contents of the above application are incorporated herein by reference in their entirety.

  Security when accessing and transmitting information is as important as security for protecting material property. Traditional security devices, such as number locks, may include devices that control access based on possessing a virtual “key”, such a virtual “key” being, for example, private It is in the form of information (for example, a passcode). A passcode is a combination of characters, such as letters, numbers, special characters, or any combination thereof. In the digital arena, passcode-based locks are emulated by digital passcode-based security devices such as automated teller machine (ATM) keypads and debit card personal identification number (PIN) keypads. Has been. These digital passcode-based security devices are typically hardware devices that are dedicated (ie, do not have a general purpose operating system / kernel to execute various functional components) and that the user can passcode A device that controls access to the system based on knowing. There are various reasons why traditional digital passcode-based security devices are implemented on dedicated devices, but above all, all general-purpose devices install malware (ie software design to overcome security without authentication). The reason can be made possible.

  For example, in point-of-sale electronic payment card transactions such as traditional Europay, MasterCard and Visa (EMV) cards or smart cards, the identity and / or authenticity of the cardholder is transferred to a paper receipt. Is confirmed by requesting the input of a PIN instead of or in addition to the signature. The user can enter the PIN into a dedicated card reader. The card reader can then obtain a PIN from the smart card. The PIN entered by the user can be compared to the PIN obtained from the smart card. Authorization to use the card may be given based on the entered PIN matching the obtained PIN.

  In the above example, a dedicated device is used instead of the general-purpose device to authorize the user. A general purpose device has an operating system that allows any third party application to run. General-purpose devices make it easy to implement applications that require security. If a universal device is available, merchants and consumers who want to use or implement a secure authentication system will be able to use a device they already own for that purpose. However, making the card reader part of a general purpose device may not be feasible because it may not be adequately protected from malware installation on the same general purpose device. One particular form of malware that may be of concern at this time is malware that performs a static analysis of a payment authentication application on a general purpose device. For example, such malware may have the ability to read memory used by the payment authentication application. When a generic device processes and stores a consumer's PIN, the generic device may cause this type of malware to find the PIN.

FIG. 1 is a data flow diagram representing a sensor input encryption technique. FIG. 2 is a block diagram illustrating an electronic device for passcode input. FIG. 3 is a block diagram illustrating an authentication system for encrypting passcode input. FIG. 4 is a system architecture diagram of an electronic device that represents a data path through which sensor inputs can be processed. FIG. 5 depicts a flowchart of a method for operating an electronic device that encrypts sensor values indicative of user input to a passcode input interface. FIG. 6 depicts a flowchart of a method of operating a computing system for decrypting a passcode by a user. FIG. 7 is a block diagram of a configured passcode input system including an electronic device and an authentication system. FIG. 8 is a schematic representation of a computer system.

  The above drawings show various embodiments of the present invention for illustrative purposes only. Those skilled in the art will readily understand from the following description that alternative embodiments of the structures and methods represented herein may be employed without departing from the principles of the invention described herein. You will understand.

  Techniques for securely entering a passcode on an electronic device are disclosed herein. The technique includes encrypting raw input events from the input device of the electronic device. By completing the passcode input, multiple raw input events can be generated. The plurality of raw input events are, for example, a plurality of touch events on a touch screen. In such a case, each raw input may represent the location of the touch event on the touch screen, and each event representing the touch location is encrypted. Thus, encryption of individual input events serves as a measure to prevent unauthorized discovery of passcodes (eg, by malware).

  The disclosed technique may be advantageous because the application memory of the electronic device does not include the fully decrypted passcode. The technique thereby prevents malware from discovering the passcode by static analysis of the application memory space on the electronic device. In addition, the input event indicating the passcode can be encrypted at the kernel level, so that malware executed at the user application level of the operating system may have a raw input event prior to encryption. Are acquired, and any analysis for reverse-engineering the passcode based on the configuration of a known passcode interface is prevented.

  In various embodiments, the encryption is based on public key cryptography. The public encryption scheme requires two separate keys. One key is kept private / secret so that it is held by the trusted computing system used for decryption. The other key is made public as known to the electronic device used for encryption. Other encryption methods may be used in place of or in combination with the disclosed technique. Such encryption methods include various symmetric and / or asymmetric encryption algorithms, such as RSA cryptography with optimal asymmetric encryption padding (RSAES-OAEP) standard cryptography or white box cryptography.

  The raw input event may be a touch event recorded by the touch screen of the electronic device. A passcode interface such as a PIN or keypad may be displayed on the touch screen. The user may enter the passcode input for authentication on the touch screen. The electronic device may encrypt the touch event that occurs due to interaction with the touch screen. The electronic device then transmits the encrypted touch event represented by the touch screen coordinates to a trusted computing system, whereby the passcode entered by the user into the trusted computing system. Are decrypted based on the encrypted touch event. In this context, an instruction, request, or any other type of message that “to cause” results in a prescribed action such as decrypting a passcode based on the encrypted touch event. Or is intended to include transmitting a signal.

  In various embodiments, only the trusted computing system performs the conversion from the encrypted raw input event to the passcode input. Instead of deciphering the passcode input on the electronic device, the input event is sent to the trusted computing system for interpretation. The trusted computing system may be external to the electronic device. The trusted computing system can then decrypt each input event to decrypt the passcode entered by the user.

  Decoding the passcode may include comparing the decrypted touch event with a configuration of the passcode interface. For example, the configuration of the passcode interface may be a keypad layout or may include a keypad layout. The keypad layout can be represented as a data structure or object. As a more specific example, the keypad layout can be generated by a trusted computing system and sent to the electronic device for decryption. As another specific example, the keypad layout can be generated by the electronic device and sent to the trusted computing system for decryption. In any case, the trusted computing system uses a passcode interface configuration, such as a keypad layout, to map sensor input events to a series of characters used to organize the passcode input. May be.

  The keypad layout may include presentation of geometry, position, relative position, animation sequence, or other variations of the keypad. The keypad may include a plurality of buttons that occupy the touch screen area of the electronic device. Each touch event may be represented by (X, Y) position coordinates, and each coordinate or set of coordinates is encrypted according to various embodiments of the disclosed technology. The passcode may then be deciphered by mapping each (X, Y) coordinate to a two-dimensional space corresponding to a particular soft button that represents the character used to organize the passcode input.

  As another specific example, the raw input event may be a touch event recorded by the camera or accelerometer of the electronic device. Malware applications may use other sensor inputs to derive passcode inputs through the passcode interface. As such, the electronic device may encrypt the raw input events at various other sensors of the electronic device to provide an additional layer of security in preventing reverse engineering of the passcode.

  In the above example, the presentation device in both the passcode interface and the input device is illustrated as a touch screen. However, audio-based passcode interfaces are contemplated as well. For example, the sensor input event may be spoken syllables, words, phrases ("sound bytes") recorded by a microphone. The configuration of the passcode interface may include valid spoken sound bytes that can be sequentially combined into a passcode input.

  FIG. 1 is a data flow diagram representing a sensor input encryption technique 100. As shown, the technique 100 includes an electronic device 102 and an authentication system 104. The electronic device 102 may be a general-purpose device having a data processing function. For example, the electronic device 102 may be a mobile phone, tablet, e-reader, other mobile or portable computing device, or other stationary computing device. The authentication system 104 may be a trusted computing system in data communication with the electronic device 102, for example, data communication over a network. The authentication system 104 may be one or more computing devices. For example, the authentication system 104 may be a server computer, a network of computing systems, a cloud computing environment, a virtualized computing environment, or any combination thereof. The communication between the authentication system 104 and the electronic device 102 may be any form of data communication including mobile communication (eg, cellular), WiFi, wireless Ethernet, wired Ethernet, or any other form of Internet connection. Good.

  The electronic device 102 may be a mobile device that presents the passcode interface 106 on an output device, such as a smartphone or tablet computer. In the illustrated embodiment, the output device is a touch screen 108. A user seeking authentication may input a sequence of inputs that organize a passcode, such as a PIN, passphrase, digital key, or any combination thereof, through a sensor (ie, input device) of the electronic device 102. In the illustrated embodiment, the sensor is a touch screen 108. However, the sensor (eg, touch panel or cursor device) for detecting the input may be different from the output device (eg, a display, projection device, speaker, or other device capable of presenting the passcode interface 106). .

  The plurality of sensor inputs 110 combine to form a sensor input stream 114, such as a touch event stream. The sensor input stream 114 is the plurality of sensor input sequences. The sensor input stream 114 may be associated with a single user, a single session, a single application, or any combination thereof. When the passcode interface 106 is presented on the touch screen 108 and the user inputs input at the passcode interface 106, the electronic device 102 captures and interprets the sensor input stream 114.

  As each sensor input 110 is captured by the sensor, the sensor input 110 is routed to the operating system of the electronic device 102 for processing. The sensor input 110 may be encrypted at any level during this data path. The data path propagates through the software stack of the electronic device 102 as shown in FIG. The encryption may be based on an asymmetric encryption method, a symmetric encryption method, or a white box encryption method. The encryption may occur at various different arbitrary levels of the software stack, as shown in FIG. Once the sensor input is encrypted, the electronic device 102 may send the encrypted sensor input 110 directly to the authentication system 104.

  In various embodiments, the portion of sensor input stream 114 is sent to authentication system 104 for decryption. In various embodiments, when the authentication system 104 receives a portion of the sensor input stream 114, the authentication system 104 may decrypt the sensor input 110 before decoding the passcode input 116 entered by the user. Good. The passcode interface configuration 118 defines a mechanism for interacting with the passcode interface and may be generated by the electronic device 102 and then sent to the authentication system 104 as well. The passcode interface configuration may specify a mapping between sensor values associated with the sensor input and a set of characters used to organize the passcode input. As an example, if the passcode interface is displayed on the touch screen 108, the passcode interface configuration may include a definition of the geometry of the passcode interface on the touch screen 108. In other embodiments, the passcode interface configuration is generated by the authentication system 104. The passcode interface configuration may be generated specifically for a session with a user interacting with the passcode input interface.

  In various embodiments, a portion of the sensor input stream 114 is interpreted to generate a passcode input 116 by contrasting the sensor input stream 114 with a known interface configuration 118. The authentication system 104 may decrypt a character or set of characters corresponding to the decrypted sensor input. Authentication system 104 may then aggregate the decrypted character or set of characters sequentially into passcode input 116. The passcode input 116 corresponds to the passcode input by the user in response to the presentation of the passcode interface.

  This technique can be applied, for example, in a financial transaction authentication process. In order to authenticate the user via the passcode input, the passcode input 116 may be contrasted with an authenticated passcode corresponding to the authorized user. For example, the authenticated passcode is stored in the financial service system 120. In some embodiments, financial services system 120 includes an authentication system 104. In some embodiments, the decryption of the passcode input 116 is performed by a module on the electronic device 102 rather than the authentication system 104.

  The authorized user and the authenticated passcode may be associated with a payment card ID 122. Payment card ID 122 may correspond to a debit card or a credit card. In the illustrated example, the payment card ID 122 is stored in the payment card 124. Payment card ID 122 is extracted via card reader 126. The card reader 126 is coupled to the electronic device 102 via wired wiring or wirelessly. Data not related to the payment card ID 122 and other passcodes is transferred to the electronic device 102. In various embodiments, payment card ID 122 and other non-passcode related data are encrypted. Data that is not related to the payment card ID 122 and other passcodes is then shared with the authentication system 104. Based on the payment ID 120 and passcode input 116, the authentication system 104 communicates with the financial service system 120, thereby confirming the user's identity and authorization, such as the user's payment.

  In another embodiment, the authenticated passcode is stored on the payment card 124. For example, an EMV credit card includes an integrated circuit (IC) chip 130 that contains the authenticated passcode associated with a user of the EMV credit card. Authorization of a user using the EMV credit card may be required to contrast the passcode input 116 with the authenticated passcode on the IC chip 130 of the EMV credit card. Thereafter, when the passcode input 116 is decrypted, the authentication system 104 may send the passcode input 116 to the electronic device 102. The passcode input 116 returned to the electronic device 102 may be similarly encrypted. The passcode input 116 can then be transmitted to the IC chip 130 for control.

  The illustrated embodiment contemplates that the sensor input is a touch event on a touch screen and the passcode interface is a keypad displayed on the touchscreen, the passcode interface being It need not be integral with the sensor device. For example, the sensor may be a vibration sensor, accelerometer, light sensor, camera, tactile sensor, or other means of detecting user interaction with a passcode interface displayed on the screen of the electronic device.

  It is also contemplated that the passcode interface is not a visual base alone. In this regard, other examples of sensor event types to which the disclosed techniques can be applied include voice input (eg, input by recognition), gesture input (eg, by gesture recognition), vibration input, eye tracking or other Includes methods for direct or indirect user input. For example, the passcode interface may be a combination of a visual interface displayed on the screen and an audio interface. The audio interface may include an audible command through a speaker and / or an audible input through a microphone. For example, the sensor input may be a voice input to a microphone, in which case the passcode interface is a user interface capable of receiving input through the voice input.

  FIG. 2 is a block diagram illustrating an electronic device 200 for passcode input. The electronic device 200 may represent the device 102 of FIG. The electronic device 200 may be a general purpose computing device. The electronic device 200 includes various modules and storage devices as described below. The electronic device 200 includes a passcode interface module 202 configured to present and maintain a passcode interface.

  In various embodiments, the passcode interface module 202 is configured to generate the passcode interface. The passcode interface module 202 may generate the passcode interface randomly or pseudo-randomly. As an example, the passcode interface may be configured as a PIN pad layout. The size, placement, position, orientation, shape and other absolute or relative geometric characteristics of the passcode interface, and elements within the passcode interface are all examples of passcode interface configurations. The passcode interface configuration may be selected to facilitate concealing a user's passcode input on the passcode interface. For example, the element of the passcode interface may be a character for selecting a passcode combination (eg, passcode input 116). The arrangement of the characters and the geometric shape and size of the characters may be randomized. Other attributes of the passcode interface configuration may be randomly generated in whole or in part. The passcode interface configuration, such as the absolute and relative (eg, relative to the display of electronic device 200) geometric characteristics of the passcode interface, may be stored in the interface configuration store 204.

  In other embodiments, the passcode interface configuration is provided by a remote system over a network, such as the authentication system 104 of FIG. For example, the passcode interface configuration may be received through the authentication communication module 206. In these embodiments, the passcode interface configuration may be stored in the interface configuration store 204 once it has been received. The passcode interface configuration may be used by the passcode interface module 202 to present the passcode interface to a user.

  When the passcode interface configuration is generated on the electronic device 200, the authentication communication module 206 may transmit the passcode interface configuration to the remote system, whereby the remote system is part of the sensor input stream. And the passcode interface configuration may be used to decrypt the passcode input.

  Passcode interface module 202 may further be configured to provide a passcode interface in various ways. As an example, the presentation of the passcode interface may include displaying or drawing the passcode interface on a touch screen according to a passcode interface configuration such as a layout configuration. The passcode interface module 202 may draw the passcode interface two-dimensionally or three-dimensionally. The passcode interface module 202 may also present the passcode interface in other ways, including animation, audio, web pages, widgets, other passive or interactive multimedia, or Presenting the passcode interface through any combination thereof is included.

  The passcode interface module 202 may be configured to maintain feedback based on user interaction with the passcode interface. For example, the passcode interface module 202 may be coupled to a touch screen of an electronic device 200, such as the touch screen 108 of FIG. This interaction allows the passcode interface to provide feedback when the user enters a character or set of characters that is part of the passcode input.

  The dialogue record is captured with an input device 205, such as the touch screen 108 of FIG. The input device 205 is controlled by the input device driver 208 of the electronic device 200. The input device driver 208 may be executed at the kernel level of the operating system of the electronic device 200.

  In various embodiments, the input device driver 208 captures an input stream from the input device 205. The input device 205 can include any input hardware (ie, one or more sensors) that can detect sensor input related to (ie, indicative of) the user's passcode interface. . The sequence of received sensor inputs may constitute the input stream.

  The electronic device 200 includes an encryption module 210. The encryption module 210 receives the input stream directly or indirectly from the input device driver 208. For example, the encryption module 210 may access the driver buffer of the input device driver 208 that contains the input stream. In another example, the encryption module 210 may respond to the interrupt generated by the input device driver 208 at the kernel level of the operating system. In yet another example, the encryption module 210 may be part of an operating system level library that interfaces with a driver at one end and a user level application at the other end.

  The encryption module 210 is configured to encrypt the sensor input of the input stream. In some embodiments, the encryption module 210 encrypts each sensor input separately. In other embodiments, a set of sensor inputs are encrypted together. In some embodiments, the content value and / or metadata value for each sensor input is encrypted separately. For example, if the sensor input is a touch event from a touch screen, the position including the X and Y coordinates of each touch screen may be encrypted. In another example, the X and Y coordinates may be encrypted separately.

  The authentication communication module 206 is configured to request a sensor input stream from the system call interface module 212 of the electronic device 200. The system call interface module 212 may be part of the operating system kernel of the electronic device 200. The system call interface module 212 can respond to the request by obtaining the sensor input stream from the encryption module 210. In various embodiments, the encryption module 210 may be integrated with the system call interface module 212, where the encryption module 210 is from the authentication communication module 206 and / or other applications. The sensor input may be dynamically encrypted based on the request.

  In response to receiving the sensor input stream, the authentication communication module 206 transmits a part of the encrypted sensor input stream to an external authentication system such as the authentication system 104 of FIG. 1 through the network. The portion may be selected from sensor inputs recorded while presenting the passcode interface on the electronic device 200.

Although FIG. 2 illustrates an encryption module 210 that encrypts the sensor input between the input device driver 208 and the system call interface module 212, other embodiments are contemplated as well in this disclosure. . For example, the encryption module 210 and the system call interface module 212 may be integrated into a single program.
In this example, the encryption module 210 and the input device driver 208 may be integrated into a single program. In yet another example, the encryption module 210 and the authentication communication module 206 may be integrated into a single program.

  The described interface configuration storage mechanism 204 may be implemented in one or more of the hardware memory components or a portion of the hardware memory component. The interface configuration store 204 may be implemented as a dynamic database service or a static data structure. The storage mechanism may be implemented by a single physical device or distributed across multiple physical devices. The storage area of the storage mechanism may be allocated at the time of execution of a module as described above, such as the passcode interface application 202.

  FIG. 3 is a block diagram illustrating the authentication system 300. As shown, the authentication system 300 includes a device communication module 302 configured to communicate with an electronic device, such as the electronic device 200 of FIG. For example, the device communication module 302 can receive a sensor input sequence, such as a touch event sequence, from an electronic device, such as the electronic device 200. In various embodiments, sensor inputs in the sensor input sequence are encrypted.

  The authentication system 300 includes a decryption module 304. The decryption module 304 is configured to decrypt the encrypted sensor input in the sensor input sequence. The decryption method in the authentication system 300 may correspond to any encryption method implemented in the electronic device that follows the encryption mechanism described for the encryption module 210. For example, the decryption method may follow an asymmetric encryption method, a symmetric encryption method, or a white box encryption method.

  In some embodiments, the decryption module 304 and / or the cryptographic module 306 are implemented as hardware components. The hardware component may be adapted to prevent external access from any external application (eg, malware application), or may otherwise access the authentication system 300. This is advantageous in that it provides an additional layer of security against attacker reserves attempting to discover the user's passcode.

  The encryption key used for the decryption can be stored in the encryption module 306 and can be obtained from the encryption module 306. The cryptographic module 306 is configured to manage an encryption key (for example, a public key or a private key) used for encryption on the electronic device and decryption on the authentication system 300. In various embodiments, the encryption module 306 assigns the encryption key to the electronic device by transmitting the encryption key through the device communication module 302.

  The authentication system 300 includes a decryption module 308. The decryption module 308 is configured to decrypt the passcode input from the user based on the sensor input sequence. For example, the decryption module 308 may receive a decrypted sensor input sequence from the decryption module 304. In some embodiments, the decryption module 308 receives a passcode interface configuration from the electronic device through the device communication module 302. In other embodiments, the decryption module 308 accesses a known passcode interface configuration (not shown) stored in the authentication system 300.

  The decryption module 308 may determine a passcode input by the user based on the decrypted sensor input sequence and the passcode interface configuration. For example, if the passcode interface is a keypad and the sensor input sequence is a touch event, the decryption module 308 maps the touch coordinates of the touch event to known character elements located on the keypad. May be. The interpreted sequence of character elements may then be deciphered as a passcode input by the user.

  The passcode input may be returned to the electronic device through the device communication module 302 to receive verification, such as verification by a card reader attached to the electronic device. The passcode input may also be passed through the financial services communication module 310 to the financial services system for verification. The financial service communication module 310 is configured to communicate with an external financial service system such as the financial service system 120 of FIG.

  One or more modules on the electronic device 200 may be implemented on the authentication system 300, and one or more modules of the authentication system 300 may be implemented on the electronic device 200. For example, the cryptographic module 306 of the authentication system 300 may be mounted on the electronic device 200, and in this case, the encryption key and the decryption key are distributed from the electronic device 200 to the authentication system 300. Become.

  FIG. 4 is a system architecture diagram of an electronic device 400, such as electronic device 102 or electronic device 200, representing data paths through which sensor inputs can be processed. The electronic device 400 includes a sensor device 402 capable of recording at hardware level 404 a sequence or stream of sensor inputs, such as the coordinates of touches detected on a touch screen (“touch events”). The hardware level 404 includes at least the physical hardware components of the electronic device 400 that are coupled to or integrated into the electronic device 400. The sensor device 402 may be a touch screen, for example. The sensor device 402 may include a sensor controller 406. The sensor controller 406 can be, for example, a dedicated integrated circuit for controlling one or more sensors in the sensor device 402. The sensor controller 406 can be, for example, a field programmable gate array (FPGA), a programmable microcontroller, or an application specific IC (ASIC). The sensor controller 406 may execute sensor firmware 408. The operation of sensor firmware 408 may be considered to occur within firmware level 410 of the system architecture.

  Sensor firmware 408 or sensor controller 406 may transmit sensor inputs to sensor device driver 412 at kernel level 414 of the system architecture. The sensor device driver 412 may be coupled to a driver buffer 416, which is a memory area for storing incoming sensor inputs. Sensor inputs received by the sensor device driver 412 may be stored in the driver buffer 416. The sensor device driver 412 is a computer program that operates or controls the sensor device 402 on behalf of the operating system 418 of the electronic device 400. Sensor device driver 412 may communicate with sensor controller 406 or sensor firmware 408 through a bus or other wired or wireless communication system.

  As shown in FIG. 4, the operating system 418 running on the electronic device 400 includes a kernel program 420. The kernel program 420 is a computer program that manages input / output requests from software running on the electronic device 400, and the requests are processed by the central processing unit (CPU) and / or other electronic components of the electronic device 400. Into data processing instructions for For example, the kernel program 420 may function as a system call interface service for the passcode authentication application 422 running at the user level 424 of the operating system 418. The kernel program 420 allows certain programs, including device drivers (eg, sensor device driver 412), to execute on the kernel level 414 with different privileges and / or restrictions than applications on the user level 424. To do. Modules executing at kernel level 414 may have higher execution privileges, may have independent address spaces, and have parallel execution threads (eg, instead of sequential execution). May be capable of interrupt-based processing, may share data with each other, may be preemptable, or any combination thereof.

  A passcode authentication application 422 such as the authentication communication module 206 of FIG. 2 may communicate with the sensor device driver 412 through the kernel program 420. For example, the passcode authentication application 422 may access sensor inputs in the sensor input stream provided by the sensor device 402.

  Encryption of sensor inputs in the sensor input stream may occur at firmware level 410, kernel level 414, user level 424, or a combination thereof. The encrypted sensor input is advantageous to protect against malware running on either kernel level 414 or user level 424. In various embodiments, the encryption key is provided on the electronic device while the decryption key is not known to the electronic device. In other embodiments, symmetric keys are used for both encryption and decryption. In this case, the symmetric key and encryption algorithm are mathematically organized as a data object (eg, a block of code or a compiled binary) from which the attacker has made no significant effort. Thus, the original symmetric key cannot be specified.

  FIG. 5 depicts a flowchart of a process 500 for operating an electronic device (eg, electronic device 102, electronic device 200, or electronic device 400) that encrypts sensor values indicative of user input to a passcode input interface. In step 502, the electronic device presents a passcode code interface on a display such as a touch screen for the user to input a passcode input. For example, the presented passcode input interface may be a keypad for authenticating a user for payment to / from the financial services system. Step 502 may be performed by the passcode input interface module 202. The passcode input interface may be presented in response to the start of a financial transaction on the electronic device, such as when a card reader coupled to the electronic device detects a credit card swipe by the user.

  A sensor input stream from the sensor of the electronic device is received at step 504. The sensor input from the sensor input stream may represent or indicate user interaction with a passcode input interface. For example, the sensor input stream can be a touch event stream from a touch screen of the electronic device. Each touch event may include coordinates of a location where a touch is detected by the touch screen. Step 504 may be performed by the input device driver 208.

  Next, in step 506, the electronic system encrypts the sensor value of the input event from the sensor input stream. The sensor value may be encrypted together with input event input metadata. If multiple sensor values are aggregated into a single input event input (eg, x and y coordinates of a touch event), the multiple sensor values may be encrypted together. In some implementations, multiple sensor inputs, such as multiple touch locations (eg, multiple sets of x and y coordinates) may be encrypted together. Step 506 may be performed by the encryption module 210 and may be performed on the kernel level of the electronic device.

  Subsequently, in step 508, the electronic device can transmit the encrypted sensor value to an external system over the network. The encrypted sensor value may be sent as an instruction, request or any other type of message or signal to cause an external system to decrypt a passcode from the encrypted sensor value. The external system may be the authentication system 300 of FIG. 3 for decrypting a passcode from the encrypted sensor value and authenticating a user based on the passcode. Step 508 may be performed by the authentication communication module 206.

  FIG. 6 depicts a flowchart of a process 600 for operating a computing system (eg, authentication system 300 of FIG. 3) for decrypting a passcode by a user. In step 602, the computing system receives encrypted sensor input values from an electronic device, such as electronic device 102, electronic device 200, or electronic device 400. In various embodiments, the sensor input value corresponds to user interaction with a passcode input interface presented on the electronic device. The encrypted sensor input value may correspond to a period during which the passcode input interface is presented on the electronic device. Step 602 may be performed by the device communication module 302 of FIG.

  Next, in step 604, the computing system decrypts the sensor value from the encrypted sensor input value. The decrypted sensor value may identify a user input event using the passcode input interface. Step 604 may be performed by the decryption module 304 of FIG.

  Once decrypted, the computing system accesses the interface configuration of the passcode input interface at step 606. The interface configuration may also specify a mapping between the sensor input value and a set of characters used to organize a passcode input, such as a character that organizes a passcode input corresponding to the sensor input value. Good. The interface configuration may be generated on the computing system or the electronic device. The interface configuration may be generated specifically for a session with a user interacting with the passcode input interface.

  Based on the interface configuration and the decoded sensor input value of the user input event, the computing system decrypts the passcode input entered by the user in step 608. Steps 606 and 608 may be performed by the decryption module 306 of FIG.

  Although the various steps, blocks or sub-processes are presented in a particular order with respect to process 500 and process 600, in alternative embodiments, routines having steps in a different order may be executed, and steps in a different order A system having blocks or sub-processes may be employed. Also, some steps, sub-processes or blocks may be deleted, moved, added, subdivided, combined and / or modified to provide alternatives or partial combinations. Each of these steps, blocks or sub-processes may be implemented in a variety of different ways. Also, although steps, sub-processes or blocks are shown here as being performed continuously at some time, some steps, sub-processes or blocks may instead be recognized by those skilled in the art. May be executed in parallel or at different times. Moreover, any particular number described herein is merely exemplary.

  FIG. 7 is a block diagram of a passcode input system 700 that includes an electronic device 702 (eg, electronic device 200 of FIG. 2) and an authentication system 704 (eg, authentication system 300 of FIG. 3). Note that the architecture shown in FIG. 7 is merely one example of the architecture of passcode input system 700, and electronic device 702 may have more or fewer components or different component configurations than shown. The various components shown in FIG. 7 may be implemented using hardware, software, firmware, or combinations thereof, including one or more signal processing integrated circuits and / or application specific integrated circuits.

  The electronic device 702 may include one or more computer readable media 710, a processing system 720, a touch subsystem 730, a display / graphics subsystem 740, a communication circuit 750, a storage device 760, and an audio circuit 770. These components may be coupled by one or more communication buses or other signal lines. The electronic device 702 can be the same as or similar to the electronic device 102, the electronic device 200, or the electronic device 400.

  The communication circuit 750 may include an RF circuit 752 and / or a port 754 for transmitting and receiving information. The RF circuit 752 includes well-known circuitry for enabling information to be transmitted over a wireless link or network to one or more other devices and for performing this function. Port 754 allows information to be transmitted over a wired link. The communication circuit 750 can communicate with the authentication system 704, for example. Communication circuit 750 may be coupled to processing system 720 via peripheral device interface 724. Peripheral interface 724 may include various known components for establishing and maintaining communication between the peripheral and the processing system 720.

  Audio circuit 770 may be coupled to an audio speaker (not shown), a microphone (not shown), an electronic card reader (not shown), or any combination thereof, and a user communicates with other users in real time. In order to enable this, it includes known circuitry for processing audio signals received from the peripheral interface 724. In some embodiments, audio circuit 770 includes a headphone jack (not shown).

  Peripheral interface 724 may couple various peripheral devices of the system, such as an electronic card reader, to one or more processors 726 and computer readable media 710. One or more processors 726 can communicate with one or more computer readable 710 via a controller 722. Computer readable media 710 can be any device or medium capable of storing code and / or data for use by one or more processors 726. Medium 710 can include a memory hierarchy, which includes, but is not limited to, a cache, main memory, and secondary memory. The memory hierarchy includes RAM (eg, SRAM, DRAM, DDRAM), ROM, FLASH, and magnetic and / or optical storage devices such as disk drives, magnetic tape, CD (compact disc) and DVD (digital video disc). It can be implemented using any combination. Medium 710 may also include a transmission medium for carrying information bearing signals indicative of computer instructions or data (with or without a carrier wave when the signal is modulated). For example, the transmission medium may include a communication network, including but not limited to the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network ( SAN), Metropolitan Area Network (MAN) and the like.

  One or more processors 726 may execute various software components stored on media 710 to perform various functions for electronic device 702. Note that the order of modules on the medium 710 does not mean the order of software stacks mounted on the medium 710. In some embodiments, the software components include an operating system 711, a communication module (or set of instructions) 712, a touch processing module (or set of instructions) 713, and an interface module such as the passcode interface module 202 of FIG. (Or set of instructions) 715 and one or more applications (or set of instructions) 718. Each of these modules and the applications described above is one or more of the functions described above and the methods described in this application (eg, computer-implemented methods and other information processing methods described herein). Corresponds to a set of instructions for executing These modules (e.g., a set of instructions) need not be implemented as separate software programs, procedures or modules, so that in various embodiments, various subsets of these modules may be combined, Otherwise it may be reconfigured. In some embodiments, media 710 may store a subset of the modules and data structures described above. Further, media 710 may store additional modules and data structures not described above.

  The operating system 711 may include various procedures, sets of instructions, software components and / or drivers for controlling and managing common system tasks (eg, memory management, storage device control, power management, etc.). , Communication between various hardware and software components may be facilitated.

  Communication module 712 includes various software components for facilitating communication with other devices using communication circuit 750 and for handling data received from RF circuit 752 and / or port 754.

  The touch processing module 713 includes various software components for performing various tasks related to the touch hardware 734, including but not limited to the I / O device controller 732 through the touch I / O device controller 732. Receiving and processing the touch input received from the / O device 730. For example, touch processing module 713 may also include software components for performing tasks related to other I / O devices (not shown).

  The interface module 715 is configured to present and maintain a passcode interface that allows the user to enter a passcode for authenticating the user's identity. Interface module 715 may include various known software components for drawing, animating, and displaying graphical objects on a display surface. In embodiments where the touch hardware 734 is a touch-sensitive display (eg, a touch screen), the interface module 715 includes components for drawing, displaying, and animating objects on the touch-sensitive display. Interface module 715 may render the graphics and provide rendering to graphics I / O controller 744 such that graphics I / O controller 744 may display the graphics on display 746. An animation instruction may be provided to a simple animation engine 722. Interface module 715 may further control audio circuit 770 to provide audio components to the passcode interface.

  One or more applications 718 may include any application installed on electronic device 702. Such applications include, but are not limited to, electronic device 200 modules, browsers, keyboard emulations, widgets, JAVA compatible applications, encryption, digital rights management, voice recognition, voice replication, location determination functions (eg, all As provided by the Global Positioning System (GPS).

  Touch I / O controller 732 is coupled to touch hardware 734 for controlling and executing various functions. Touch hardware 732 communicates with processing system 720 via touch I / O device controller 732. The touch I / O device controller 732 includes various components (eg, scanning hardware) for processing user touch input. One or more other input controllers (not shown) send / receive electrical signals to / from other I / O devices (not shown). Other I / O devices may include physical buttons, dials, slider switches, sticks, keyboards, touchpads, additional display screens, or any combination thereof.

  When implemented as a touch screen, touch hardware 734 displays visual output on the GUI to the user. The visual output may include text, graphics, video, and any combination thereof. Some or all of the visual output may correspond to a user interface object. Touch hardware 734 forms a touch sensitive surface that accepts touch input from a user. Touch hardware 734 and touch controller 732 (with any associated module and / or set of instructions in media 710) touch on touch hardware 734 or a state close to touch (and any touch movement or release). And tracking the detected touch input into an interaction with a graphical object, such as one or more user interface objects. If touch hardware 734 and display 746 are implemented as touch screens, the user can interact directly with the graphical objects displayed on the touch screen. Alternatively, if the hardware 734 is implemented as a touch device other than a touch screen (eg, a touchpad), the user can interact indirectly with a graphical object displayed on another display screen. .

  In embodiments where the touch hardware 734 is a touch screen, the touch screen uses LCD (Liquid Crystal Display) technology, LPD (Light Emitting Polymer Display) technology, OLED (Organic Light Emitting Diode) technology, or OEL (Organic Electroluminescence). Although other display technologies may be used in other embodiments.

  Feedback may be provided by touch hardware 734 based on the user's touch input and the state of what is being displayed and / or the state of the computing system. Feedback can be optically (eg optical signal or displayed image), mechanically (eg tactile feedback, touch feedback, force feedback), electrically (eg electrical stimulation), olfactory, acoustic (E.g., a beep or the like), or any combination thereof, and may be transmitted in a variable or non-changeable manner.

  In some embodiments, the peripheral interface 724, the one or more processors 726, and the memory controller 722 may be implemented on a single chip. In some other embodiments, these may be implemented on separate chips. Storage device 760 may be any suitable medium for storing data. For example, the medium includes volatile memory (eg, cache, RAM), non-volatile memory (eg, flash, hard disk drive), or both, and the data includes pages used for transition animations. Is included.

  2-4 and 7, the blocks, components, and / or modules associated with electronic device 200, authentication system 300, or electronic device 702 may each be implemented in the form of dedicated circuitry, or one or more It may be implemented in the form of a suitably programmed programmable processor, or a combination thereof. For example, the described modules may be implemented as instructions on a tangible storage memory that can be executed by a processor or controller on the machine. The tangible storage memory may be volatile or non-volatile memory. In some embodiments, the volatile memory may be considered “non-transitory” in the sense that it is not a transient signal. The operation of the module may be a processor or other computing device such as a single board chip, application specific integrated circuit, field programmable field array, network available computing device, virtual machine terminal device, cloud based computing It may be possible when executed by a terminal device, or any combination thereof.

  Each of the modules may operate independently of the other modules. Some or all of the modules may be executed on the same host device or may be executed on separate devices. The separate devices may be coupled via an interconnect or wirelessly via a communication module to coordinate its operation. Some or all of the modules may be combined as a single module.

  A single module may be divided into a plurality of sub-modules, each sub-module performing a separate one or more method steps of the single module. In some embodiments, the modules can share access to the memory space. One module may access data that is accessed or converted by another module. If these modules share a physical or virtual connection directly or indirectly so that data accessed or modified from one module can be accessed by another module, These modules can be considered “coupled” to each other. In some embodiments, some or all of the modules can be upgraded or modified remotely. Electronic device 200, authentication system 300, or electronic device 702 may include additional modules, a smaller number of modules, or different modules for various applications.

  FIG. 8 is a schematic representation of the computer system 800. Computer system 800 is intended to represent a hardware device in which any of the modules and components illustrated in the example of FIG. 3 (and any other modules and / or components described herein) may be implemented. Yes. As shown, computer system 800 includes a processor 802, memory 804, non-volatile memory 806, and a network interface 808. Various common components (eg, cache memory) have been omitted for simplicity of illustration. The computer system 800 can be of any applicable known or conventional type, such as a personal computer (PC), a server class computer or a mobile device (eg, smart phone, card reader, tablet computer, etc.). The plurality of components of computer system 800 may be coupled together via a bus and / or through any other known or conventional form of interconnection.

  Those skilled in the relevant art will understand that the term “machine-readable (storage) medium” or “computer-readable (storage) medium” includes any type of device accessible by the processor 802. Let's go. Memory 804 is coupled to processor 802 by bus 810, for example. Memory 804 is illustrative and may include random access memory (RAM) such as dynamic RAM (DRAM) and static RAM (SRAM). Memory 804 may be local, remote or distributed.

  Bus 810 may also couple processor 802 to non-volatile memory 806 and drive unit 812. The non-volatile memory 806 may be a hard disk, a magneto-optical disk, an optical disk, a read-only memory (ROM), such as a CD-ROM, an erasable programmable read-only memory (EPROM), or an electrically erasable memory. It may be a programmable read only memory (EEPROM), a magnetic or optical card, or other form of mass data storage. The non-volatile storage device 806 can be local, remote or distributed.

  The module described in FIG. 3 may be stored in the non-volatile memory 806, the drive unit 812, or the memory 804. The processor 802 may execute one or more modules stored in the memory component.

  Bus 810 also couples processor 802 to network interface device 808. Interface 808 may include one or more modems or network interfaces. The modem or network interface can be considered part of the computer system 800. Interface 808 includes an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface (eg, “direct PC”) or other interface for coupling a computer system to another computer system. obtain.

  Each of the sections or drawings of this disclosure may illustrate different implementations and different relationships between elements and terms. However, similar elements and terms referred to in different sections of the disclosure, and drawings are meant to be interchangeable in various embodiments.

  Alternative terms and synonyms may be used for any one or more of the terms described herein, and whether or not the terms are detailed or described herein The meaning is not necessarily recognized. The description of one or more synonyms does not exclude the use of other synonyms. Use of examples in any part of this specification, including examples of any terms described herein, is merely exemplary and further extends the scope and meaning of this disclosure or any of the exemplified terms It is not limited. Likewise, the present disclosure is not limited to the various embodiments described herein.

  Those skilled in the art will appreciate that the present invention may be practiced in other forms and methods not shown below. The use of a term representing a relationship, such as first or second, is used only to distinguish one thing or action from another, if any, between such things or actions. It does not necessarily require or imply actual relationships or order.

  As used herein, the terms are “connected”, “coupled”, or any variant thereof, whether directly or indirectly when applied to a module of the system. Any connection or coupling between two or more elements in any way is meant. The coupling of connections between the elements can be physical, logical, or any combination thereof. Where the context permits, words using the singular or plural in the above detailed description may also include the plural or singular, respectively. The word “or” for an enumeration of two or more items encompasses all of the following word interpretations: any item in the enumeration, all items in the enumeration, and items in the enumeration. Any combination. The word “portion” or “portioned” for a sequence includes any subset or the entire sequence.

  References herein to “various embodiments” or “some embodiments” include specific features, structures, or characteristics described in connection with the embodiments in at least one embodiment of the disclosure. Means that Embodiments referenced to them and alternative embodiments (eg, referred to as “other embodiments”) may not be mutually exclusive of one another. Moreover, the various features described may be shown in some embodiments but not in other embodiments. Similarly, the various requirements described may be requirements of some embodiments but not other embodiments.

  The above description and drawings are illustrative and should not be construed as limiting the invention to the precise forms disclosed. Those skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure. Numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. A reference to one embodiment or an embodiment in the present disclosure may, but need not be, a reference to the same embodiment. And such a reference means at least one of the embodiments.

In summary, the present disclosure includes:
1. A method of operating a mobile device to prevent unauthorized capture of passcode input in a financial transaction, comprising:
Initiating the financial transaction when a card reader coupled to the mobile device detects a payment card swipe from a user;
Presenting a passcode input interface on a touch screen of the mobile device for a user to input a passcode;
Receiving a touch event from the touch screen while presenting the passcode input interface;
Encrypting the location of the touch event, which is a location indicating where the user touch occurred on the touch screen;
In order to have an external system authenticate the user by decrypting the passcode based at least in part on the encrypted location of the touch event, the encrypted location is passed over the network to the external system. Transmitting the method.
2. The method of claim 1, further comprising encrypting the metadata input of the touch event along with the location of the touch event.
3. The method of claim 1, wherein the step of encrypting the location of the touch event comprises using asymmetric cryptography.
4). The method of claim 1, wherein the step of encrypting the location of the touch event is performed in conjunction with encryption of the location of another touch event.
5. The method of claim 1, further comprising transmitting data indicative of a screen geometry of the touch screen to the external system.
6). A method of operating an electronic device to prevent unauthorized capture of passcode input in a financial transaction, comprising:
Presenting a passcode input interface on the electronic device to allow a user to input a passcode input;
Receiving an input event from a sensor of the electronic device, wherein the input event indicates at least a portion of the passcode input by the user and includes at least a sensor value measured by the sensor; Process,
Encrypting the sensor value of the input event;
Transmitting the encrypted sensor value over the network to the external system to cause the external system to decrypt the passcode input based at least in part on the encrypted sensor value. .
7). Transmitting the interface configuration of the passcode input interface to the external system, wherein the interface configuration specifies a mapping between a sensor value associated with the sensor input and a set of characters for organizing the passcode input The method according to claim 6, further comprising the step of:
8). The method of claim 7, wherein the interface configuration includes a geometric property of the passcode input interface presented on a touch screen of the electronic device.
9. The method of claim 7, further comprising encrypting the interface configuration before transmitting the interface configuration.
10. The method of claim 7, further comprising: generating a randomized arrangement for the passcode input interface, wherein the randomized arrangement is recorded as part of the interface configuration.
11. 7. The method of claim 6, further comprising: transmitting a screen geometry of a display device of the electronic device to the external system, wherein the passcode input interface is displayed on the display device.
12 The method of claim 6, wherein the step of encrypting the sensor value of the input event comprises using a white box encryption technique.
13. The method of claim 6, wherein the step of encrypting the sensor value of the input event comprises using asymmetric cryptography.
14 A method of operating a computing system for decoding a passcode based at least in part on a sensor input comprising:
Receiving an encrypted sensor input value from an electronic device, wherein the encrypted sensor input value corresponds to a user interaction with a passcode input interface on the electronic device;
Decrypting the encrypted sensor input value to determine the user input event;
Accessing the interface configuration of the passcode input interface for specifying a mapping between sensor input values and sets of characters for organizing the passcode; and a user based at least in part on the user input event and the interface configuration Deciphering the passcode input by the method.
15. The method of claim 14, further comprising generating the interface configuration specifically for a session with a user interacting with the passcode input interface.
16. The step of generating the interface configuration includes generating the interface configuration as a randomized arrangement of interactive buttons, wherein the step of accessing the interface configuration accesses the location of the interactive button. 16. The method of claim 15, comprising:
17. The method of claim 16, further comprising transmitting the interface configuration to the electronic device to allow the passcode input interface to be displayed on the electronic device.
18. 15. The method of claim 14, wherein the step of accessing the interface configuration includes receiving an encrypted configuration from the electronic device and decrypting the encrypted configuration as the interface configuration. the method of.
19. A computer program product encoded on a computer storage medium, operable when executed by a processor, said computer program product comprising:
As the user presents a passcode input interface on the electronic device for inputting the passcode input,
At this time, the input event indicates at least part of the passcode input by the user and includes at least a sensor value measured by the sensor so as to receive an input event from the sensor of the electronic device. like,
Encrypting the sensor value of the input event; and
Operable to transmit the encrypted sensor value over the network to the external system to cause the external system to decrypt the passcode input based at least in part on the encrypted sensor value. , Computer program products.
20. Memory,
An electronic device presenting a passcode input interface for a user to input a passcode input;
A sensor for storing a sensor input sequence in a memory, wherein the sensor input sequence indicates user interaction with the passcode input interface;
An electronic device comprising: a processor that encrypts sensor inputs of the sensor input sequence and transmits the encrypted sensor inputs over a network to a remote system to decrypt the passcode input by the user.
21. A network interface for receiving a sensor input sequence from an electronic device, wherein the sensor input sequence indicates user interaction with a passcode input interface on the electronic device;
A security component for decrypting the encrypted sensor input of the sensor input sequence;
A computer server system comprising: a processor configured to decode a passcode input by a user based at least on the decoded sensor input and data indicative of the geometry of the passcode input interface.

Claims (21)

A method of operating a mobile device to prevent unauthorized capture of passcode input in a financial transaction, comprising:
Initiating the financial transaction when a card reader coupled to the mobile device detects a payment card swipe from a user;
Presenting a passcode input interface on a touch screen of the mobile device for a user to input a passcode;
Receiving a touch event from the touch screen while presenting the passcode input interface;
Encrypting the location of the touch event, which is a location indicating where the user touch occurred on the touch screen;
In order to have an external system authenticate the user by decrypting the passcode based at least in part on the encrypted location of the touch event, the encrypted location is passed over the network to the external system. Transmitting the method.   The method of claim 1, further comprising encrypting the touch event metadata input along with the location of the touch event.   The method of claim 1, wherein the step of encrypting the location of the touch event comprises using an asymmetric cryptography.   The method of claim 1, wherein the step of encrypting the location of the touch event is performed in conjunction with encryption of the location of another touch event.   The method of claim 1, further comprising transmitting data indicative of a screen geometry of the touch screen to the external system. A method of operating an electronic device to prevent unauthorized capture of passcode input in a financial transaction, comprising:
Presenting a passcode input interface on the electronic device to allow a user to input a passcode input;
Receiving an input event from a sensor of the electronic device, wherein the input event indicates at least a portion of the passcode input by the user and includes at least a sensor value measured by the sensor; Process,
Encrypting the sensor value of the input event;
Transmitting the encrypted sensor value over the network to the external system to cause the external system to decrypt the passcode input based at least in part on the encrypted sensor value. .   Transmitting an interface configuration of the passcode input interface to the external system, wherein the interface configuration specifies a mapping between sensor values from the sensors and a set of characters for organizing the passcode input. The method of claim 6, further comprising a step.   The method of claim 7, wherein the interface configuration includes geometric characteristics of the passcode input interface presented on a touch screen of the electronic device.   The method of claim 7, further comprising encrypting the interface configuration before transmitting the interface configuration.   The method of claim 7, further comprising generating a randomized arrangement for the passcode input interface, wherein the randomized arrangement is recorded as part of the interface configuration.   The method of claim 6, further comprising: transmitting screen geometry of a display device of the electronic device to the external system, wherein the passcode input interface is displayed on the display device.   The method of claim 6, wherein the step of encrypting the sensor value of the input event comprises using a white box encryption technique.   The method of claim 6, wherein the step of encrypting the sensor value of the input event comprises using an asymmetric cryptographic technique. A method of operating a computing system for decoding a passcode based at least in part on a sensor input comprising:
Receiving an encrypted sensor input value from an electronic device, wherein the encrypted sensor input value corresponds to a user interaction with a passcode input interface on the electronic device;
Decrypting the encrypted sensor input value to determine the user input event;
Accessing the interface configuration of the passcode input interface for specifying a mapping between sensor input values and a set of characters for organizing the passcode; and a user based at least in part on the user input event and the interface configuration Deciphering the passcode input by the method.   The method of claim 14, further comprising generating the interface configuration specifically for a session with a user interacting with the passcode input interface.   The step of generating the interface configuration includes generating the interface configuration as a randomized arrangement of interactive buttons, wherein the step of accessing the interface configuration accesses the location of the interactive button. The method according to claim 15, comprising:   The method of claim 16, further comprising transmitting the interface configuration to the electronic device to allow the passcode input interface to be displayed on the electronic device.   15. The method of claim 14, wherein the step of accessing the interface configuration includes receiving an encrypted configuration from the electronic device and decrypting the encrypted configuration as the interface configuration. the method of. A computer program product encoded on a computer storage medium, operable when executed by a processor, said computer program product comprising:
As the user presents a passcode input interface on the electronic device for inputting the passcode input,
At this time, the input event indicates at least part of the passcode input by the user and includes at least a sensor value measured by the sensor so as to receive an input event from the sensor of the electronic device. like,
Encrypting the sensor value of the input event; and
Operable to transmit the encrypted sensor value over the network to the external system to cause the external system to decrypt the passcode input based at least in part on the encrypted sensor value. , Computer program products. Memory,
An electronic device presenting a passcode input interface for a user to input a passcode input;
A sensor for storing a sensor input sequence in a memory, wherein the sensor input sequence indicates user interaction with the passcode input interface;
An electronic device comprising: a processor that encrypts sensor inputs of the sensor input sequence and transmits the encrypted sensor inputs over a network to a remote system to decrypt the passcode input by the user. A network interface for receiving a sensor input sequence from an electronic device, wherein the sensor input sequence indicates user interaction with a passcode input interface on the electronic device;
A security component for decrypting the encrypted sensor input of the sensor input sequence;
A computer server system comprising: a processor configured to decode a passcode input by a user based at least on the decoded sensor input and data indicative of the geometry of the passcode input interface.

Images