JP2021536601A - Anti-replay authentication system and method - Google Patents

Abstract

Systems and methods for authentication that are resistant to replay attacks are provided. A device may be used to capture the user's image data and authenticate or identify the user. Authentication information can be obtained by processing and analyzing the captured image data. Data regarding the state of the imager and the captured image data can be used for fraud detection. Data can be collected when image data is processed and analyzed. The state of the imager and the captured image data is unlikely to be repeated. The detection and repetition of the state of the imaging device and the captured image data can be a factor that increases the likelihood that a replay attack is taking place. The device can be used to make a transaction.

Description

Mutual reference to related applications [0001] This application claims the priority and interests of US Provisional Patent Application No. 62 / 722,629 filed on August 24, 2018, filed on July 29, 2016. This is a continuation of the international patent application PCT / US Patent Application Publication No. 2017/044371 filed on July 28, 2017, claiming the priority and interests of US Provisional Patent Application No. 62 / 368,969. , Partial continuation of US Patent Application Publication No. 16 / 247,835 filed January 15, 2019, the entire contents of which are incorporated herein by reference.

Background of the Invention [0002] Replay attacks play a major role in fraudulent transactions, especially electronic transactions. In a replay attack, data from a previous transaction is fraudulently or maliciously repeated in a new transaction, especially to authenticate the user or device.

[0003] Machine-readable secure identification tokens, such as barcodes on driver's licenses or other types of ID cards, are known to be used during authentication. When using a mobile phone camera, conventional physical tokens can be scanned by a digital camera and used for authentication or identification. However, such static security tokens are vulnerable to replay attacks.

INDUSTRIAL APPLICABILITY [0004] Therefore, there is a need for improved systems and methods for authenticating user identification that are resistant to replay attacks.

[0005] In one aspect of the invention, a method of performing anti-replay analysis is provided. Methods and systems for token-based user authentication that are resistant to replay attacks are provided. A user device equipped with a camera can be used to take an image of the physical token during a transaction. In addition or instead, a user device with a camera can be used to capture a user's "selfie" image or photo or video clip during a transaction. Data regarding the state of the image, the state of the camera or the state of the user device can be collected at the time of the transaction. Such data can be used to create singularity values or "nonces" that may not be repeatable or are very unlikely to be repeated. If the nonce data is repeated exactly the same within a subsequent transaction, it is highly unlikely that the nonce data will be repeated, so such repetition may indicate that the subsequent transaction is likely to be a replay attack. Can be emitted.

[0006] In one aspect, a method for authenticating a user or transaction is provided. This method uses a user device to capture image data of a physical token, the image data including a graphical code, capturing, obtaining identification information about the user from the image data, (1). Collecting nonce data, including the physical state of the user device, or (2) the characteristics of the image data that is unique to the user device, at some point during the collection of the nonce data, and (1) identification information, And (2) include authenticating a user or transaction using one or more processors based on nonce data.

[0007] In some embodiments, the physical token comprises a graphical code containing identifying information about the user. In some embodiments, the physical token is issued by the authoritative entity and is associated with the identification of the user.

[0008] In some embodiments, the nonce data is as follows: (i) one or more operating parameters of the image pickup device coupled to the user device for the operation of capturing the image data, (ii) the image pickup device. Alternatively, it includes at least two of the location information about the user device and (iii) the characteristics of the image data derived from the image processing of the image data. In some cases, nonce data about the physical state of the user device includes data collected by one or more sensors. In some cases, the physical state of the user device contains data that indicates the physical state of the component of the user device, and in some situations, the component is a group that includes an image pickup device, a power supply unit, a processor, and memory. Is selected from. In some embodiments, the characteristics of the image data are as follows: (i) one or more parameters brought about during image processing, (ii) one or more properties of unprocessed image data, and (iii). ) Includes at least one of the properties of one or more of the processed image data.

[0009] In some embodiments, the nonce data is encrypted so that when the nonce data contains more than one factor, those factors are not accessible by one or more processors. In some embodiments, the nonce data and identification data are compared to previously collected nonce data and previously collected identification data to determine the presence of a replay attack.

[0010] In another aspect, a system for authenticating a user or transaction is provided. The system includes a server that communicates with a user device, which is configured to allow the user to make a transaction, which is (i) a memory for storing a set of software instructions, and (ii). At some point during the collection of nonce data, one or more processors, including (1) the physical state of the user device and (2) the characteristics of the image data that are unique to the user device. Receiving in, the image data includes a graphical code, receiving, receiving image data of a physical token held by the user, obtaining identification information about the user from the image data, and ( Includes one or more processors configured to execute a set of software instructions to perform 1) identification information and (2) authentication of a user or transaction based on nonce data.

[0011] In some embodiments, the physical token comprises a graphical code containing identifying information about the user. In some embodiments, the physical token is issued by the authoritative entity and is uniquely associated with the user's identity.

[0012] In some embodiments, the nonce data is as follows: (i) one or more operating parameters of the image pickup device coupled to the user device for the operation of capturing the image data, (ii) the image pickup device. Alternatively, it includes at least two of the location information about the user device and (iii) the characteristics of the image data derived from the image processing of the image data. In some cases, at least one of the operating parameters of one or more imaging devices is modified in response to instructions generated by the system. In some embodiments, the physical state of the user device comprises data collected by one or more sensors. In some embodiments, the physical state of the user device includes data indicating the physical state of the component of the user device, the component being selected from the group including an image pickup device, a power supply unit, a processor and a memory. In some embodiments, the characteristics of the image data are as follows: (i) one or more parameters brought about during image processing, (ii) one or more properties of unprocessed image data, and (iii). ) Includes at least one of the properties of one or more of the processed image data. In some embodiments, the nonce data and identification data are compared to previously collected nonce data and previously collected identification data to determine the presence of a replay attack.

[0013] In another aspect, a method for authenticating a user or transaction with anti-replay protection is provided. This method uses the user device to capture the image data of the physical token, (1) the physical state of the user device involved in the operation of capturing the image data, or (2) an image specific to the user device. Collecting nonce data about the characteristics of the data at some point during the collection of the nonce data, obtaining identification information about the user device or user, using one or more processors to obtain the nonce data and the identification information. Whether the nonce data and the previously collected nonce state data are the same, using a comparison with previously collected nonce data and previously collected identification information, and using one or more processors. Includes determining the presence of a replay attack based on somehow. In some embodiments, the nonce data relates to: (i) one or more operating parameters of the image pickup device coupled to the user device during the operation of capturing the image data, (ii) the image pickup device or the user device. Includes at least one of the characteristics of one or more of the image data derived from the location information and the image processing of the (iii) image data.

Reference Incorporation [0014] All publications, patents and patent applications referred to herein are specifically and individually indicated so that their respective publications, patents or patent applications are incorporated by reference. Incorporated herein by reference to the same extent as.

BRIEF DESCRIPTION OF THE DRAWINGS [0015] A better understanding of the features and advantages of the invention can be obtained by reference to the following detailed description of exemplary embodiments utilizing the principles of the invention.

[0016] An example of an apparatus according to an embodiment of the present invention that can promote a transaction requiring authentication is shown. [0017] An example of using a user device to capture a physical token for authentication according to an embodiment of the present invention is shown. [0018] An example of a user device for capturing a self-portrait image for authentication according to an embodiment of the present invention is shown. [0019] An example of data that can be used as nonce data generated during image capture and processing according to an embodiment of the present invention is shown. [0020] An example of data that can be used as nonce data generated during capture and processing of user image data according to an embodiment of the present invention is shown. [0021] An example of how nonce data can be generated or stored according to an embodiment of the present invention is shown. [0022] An example of how data can be stored for various transactions according to an embodiment of the present invention is shown. [0023] Demonstrates how nonce data and identification data can be used to form authentication parameters according to embodiments of the present invention. [0024] An example of using identification data and nonce data to identify a user and / or device according to an embodiment of the present invention is shown. [0025] An example of using nonce data to identify a user and / or device according to an embodiment of the present invention is shown. [0026] An example of an entity involved in an authentication event according to an embodiment of the present invention is shown. [0027] An example of using a checksum to derive a nonce data or nonce factor is shown. [0027] An example of using a checksum to derive a nonce data or nonce factor is shown. [0027] An example of using a checksum to derive a nonce data or nonce factor is shown.

Detailed Description of the Invention [0028] Although preferred embodiments of the invention have been illustrated and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Here, many modifications, modifications and substitutions will be recalled to those skilled in the art without departing from the present invention. In practicing the invention, it should be understood that various alternatives to the embodiments of the invention described herein can be used.

[0029] The present invention provides a system and method for user authentication using tokens, which is resistant to replay attacks. Various aspects of the invention described herein may apply to any of the specific applications described below. The present invention may be applied as an authentication system or as a stand-alone anti-replay system, fraud detection software or any transaction process requiring identification verification or authentication. It should be understood that various aspects of the invention can be recognized individually, collectively or in combination with each other.

[0030] A transaction can be an event or activity that requires user authentication or verification of identification. User identification information may be provided on the basis of a physical token such as a machine-readable secure identification token (eg, a barcode on the user's ID card). In online transactions, users can scan physical tokens and transmit identity information to service providers to verify identification. In some cases, biometric authentication with facial recognition can be used for identification verification or authentication. For example, the user can be authenticated by capturing a selfie image or face recognition. In some cases, capturing a selfie image can be used as an alternative to taking an image of a physical token. In some cases, capturing a selfie image can be done in addition to authenticating with a physical token. Transactions may be made online, in which case the data may be easily intercepted. For example, information about the user in the first transaction may be recorded. The recorded information may be used in subsequent transactions in a replay attack so that it appears to the same user as it appeared in the first transaction or allows subsequent transactions to proceed. The information recorded may relate to the terms of the first transaction, such as scanned image data used within the first transaction or nonce data related to the condition of the imager. Detecting repeated nonce data may indicate that a replay attack is taking place.

[0031] In some embodiments, nonce data relating to the state of the scanned image or image pickup device during the first transaction may be collected. The nonce data may contain one or more sets of singularity values (eg, nonce factors) that may realistically occur only once and do not naturally repeat. Therefore, repeated nonce data can be a source of suspicion that a replay attack may be taking place. The nonce data may include data that may be related to the internal state of the imaging device or components of the imaging device, or may include data that may be collected in relation to the scanned image, including user identification data. The nonce data may include image capture information such as metadata, location information or any other information related to the imaging device. The nonce data may also include data generated while processing the image for contextual analysis.

[0032] Nonce data can be collected using one or more sensors and one or more processors. Sensors and processors can be mounted on the device. Sensors and processors may or may not require the use of external signals or data collected from outside the device.

[0033] FIG. 1 shows an example of a device 100 that can assist in conducting a transaction requiring authentication according to an embodiment of the present invention. The device may be a user device including a display 102 and may include an interface 104 for making a transaction using the device. This device includes one or more memory storage units 106, one or more processors 108, one or more communication units 110, one or more power supplies 112 and / or one or more sensors 114, 116. May include.

[0034] The user device 100 may be an electronic device that can assist in a transaction or assist in identifying and / or authenticating a user. The user device can be a mobile device (eg, a smartphone, tablet, pager, personal digital assistant (PDA)), a computer (eg, a laptop computer, desktop computer, server or any other type of device. The user device may be handheld. The user device may be lightweight. In some embodiments, the user device weighs 10 kg, 8 kg, 6 kg, and may optionally be portable. It can be 5 kg, 4 kg, 3 kg, 2 kg, 1.5 kg, 1 kg, 0.7 kg, 0.5 kg, 0.3 kg, 0.1 kg, 0.05 kg, 0.01 kg, 0.005 kg or 0.001 kg or less.

[0035] The user device may be a network device to which a network can be connected, such as a local area network (LAN), a wide area network (WAN) such as the Internet, a telecommunications network, a data network, and any other type of network. The user device may be capable of direct or indirect wireless communication. User devices may be capable of peer-to-peer (P2P) communication and / or communication with cloud-based infrastructure.

[0036] The user device can be used during a transaction (financial transaction, etc.) with a transaction entity. Transactions can include the exchange of finance (eg, money, short-term securities, debt, loans, etc.). Transactions can include the exchange of goods or services. Transactions can include the exchange of information. Transactions may include verifying a user's identity or authenticating user access to information or a place. In some examples, the transaction may include the exchange of sensitive and / or private data. A trading entity can include any entity involved in a transaction. The trading entity can be an individual, a company, a limited partnership, a company, an organization, a group, an organizer or any other type of entity. In some examples, the trading entity is a financial institution (eg, a bank, a financial management company), a retailer (eg, a store, an online merchant), a social networking company, a non-profit organization, a medical organization, an educational institution, an administrative body or It may include government agencies or any other type of entity. The user device may be able to communicate directly or indirectly with the trading entity. In some embodiments, the trading entity may use a server or other type of online host, or may be a server or other type of online host. The user device may communicate with the trading entity's server and / or other host device.

[0037] The user device may include a display 102. The display can display one or more still images (eg, photographs) and / or moving images (eg, video) captured by the image pickup device in real time. The display may be able to present information to the user. The display can visually show the information. The information shown on the display may be mutable. The display may include a screen such as a liquid crystal display (LCD) screen, a light emitting diode (LED) screen, an organic light emitting diode (OLED) screen, a plasma screen, an electronic ink screen, a touch screen, any other type of screen or display. .. The display may or may not accept user input.

[0038] The display may show a graphical user interface 104. The graphical user interface can be part of a browser, software or application that can assist the user in making a transaction using the device. The interface may allow the user to self-identify using the device. The user can access the user account using the device. User accounts can be used during transactions. The user device may be capable of operating one or more software applications. One or more applications may or may not be involved in electronic transactions. One or more applications may require or use user identification and / or authentication.

[0039] The user device may be able to accept input from the user dialogue device. Examples of such user interaction devices may include keyboards, buttons, mice, touch screens, touchpads, joysticks, trackballs, cameras, microphones, motion sensors, thermal sensors, inertial sensors or any other type of user interaction device. ..

[0040] The user device may include one or more memory storage units 106, which is a non-transitory computer-readable medium containing code, logic, or instructions for performing one or more steps. Can include. The user device may include, for example, one or more processors 108 capable of performing one or more steps according to a non-transient computer readable medium. One or more memory storage units may store one or more software applications or commands related to the software application. One or more processors may perform the steps of a software application individually or collectively.

[0041] The communication unit 110 may be provided to the device. The communication unit may allow the user device to communicate with the external device. The external device can be a device of a trading entity, a server, or a cloud-based infrastructure. Communication may include communication on the network or direct communication. The communication unit may enable wireless or wired communication. Examples of wireless communication may include, but are not limited to, WiFi, 3G, 4G, LTE, radio frequency, Bluetooth, infrared or any other type of communication. The communication unit may or may not assist in collecting the data used to determine the nonce data.

The device may have an onboard power supply 112. Instead, an external power source may provide power to power the user device. The external power source may provide power to the user device via a wired or wireless connection. The onboard power supply may power the entire user device or one or more individual components of the wireless device. In some embodiments, multiple onboard power sources may be provided that can power different components of the device. For example, one or more sensors in the device may be powered using a source separate from one or more memory storage units, processors, communication units and / or displays in the device.

[0043] The user device can include an image pickup sensor and serves as an image pickup device 114. The image pickup device 114 may be on the board of the user device. The imaging device may include hardware and / or software elements. In some embodiments, the image pickup device can be a camera operably coupled to the user device. In some alternative embodiments, the image pickup device can be located outside the user device, and the image data of the graphical element, such as a barcode, is the user device by the communication means described elsewhere herein. Can be transmitted to. The image pickup device can be controlled by an application / software configured to scan the visual code. In some embodiments, the camera may be configured to scan a barcode on an ID card, a barcode on a passport, a barcode on a document or a barcode displayed on an external display. In some embodiments, the software and / or application may be configured to activate the camera on the user device and scan the code. In other embodiments, the camera may be controlled by a processor natively embedded within the user device.

[0044] The image pickup apparatus 114 may be a fixed lens camera or an autofocus lens camera. The image pickup apparatus can utilize a complementary metal oxide semiconductor (CMOS) sensor that generates an electric signal according to the wavelength of light. Image data can be created by processing the resulting electrical signals. The image pickup device may include a lens configured to direct light onto the image pickup sensor. The camera can be a movie camera or a video camera that captures moving image data (eg, video). The camera can be a still camera that captures a still image (eg, a photo). The camera can capture both moving image data and still images. The camera can switch between capturing video data and still images. Although the particular embodiments presented herein are described in the context of a camera, the present disclosure can be applied to any suitable imaging device, and any description of this specification with respect to a camera is optional. It should be understood that it can be applied to various image pickup devices and can be applied to other types of image pickup devices. The camera may include optical elements (eg, lenses, mirrors, filters, etc.). The camera can capture a color image, a grayscale image, and the like.

[0045] The image pickup device 114 may be a camera used to capture a visual image around the device. Any other type of sensor can be used, such as an infrared sensor that can be used to capture thermal images around the device. The image pickup sensor can collect information at any point along the electromagnetic spectrum and can appropriately generate a corresponding image.

[0046] In some embodiments, the imaging device may be capable of operating with very high resolution. The imaging sensor is about 100 μm, 50 μm, 10 μm, 5 μm, 2 μm, 1 μm, 0.5 μm, 0.1 μm, 0.05 μm, 0.01 μm, 0.005 μm, 0.001 μm, 0.0005 μm or 0.0001 μm or more. Can have resolution. The image sensor may be capable of collecting images of 4K or higher.

[0047] The image pickup apparatus can capture an image frame or a series of image frames with a specific image resolution. In some embodiments, the resolution of the image frame can be determined by the number of pixels in the frame. In some embodiments, the image resolution is approximately 352 x 420 pixels, 480 x 320 pixels, 720 x 480 pixels, 1280 x 720 pixels, 1440 x 1080 pixels, 1920 x 1080 pixels, 2048 x 1080 pixels, 3840 x. It can be 2160 pixels, 4096 × 2160 pixels, 7680 × 4320 pixels or 15360 × 8640 pixels or more.

[0048] The image pickup apparatus 114 can capture a series of image frames at a specific capture rate. In some embodiments, the series of images is about 0.0001 seconds, 0.0002 seconds, 0.0005 seconds, 0.001 seconds, 0.002 seconds, 0.005 seconds, 0.01 seconds, 0. It can be captured at a rate of 1 image or less every 02 seconds, 0.05 seconds, 0.1 seconds, 0.2 seconds, 0.5 seconds, 1 second, 2 seconds, 5 seconds or 10 seconds. In some embodiments, the capture rate may vary depending on user input and / or external conditions (eg, illumination brightness).

The state of the imaging device 114 may include information relating to one or more operating parameters of the camera or imaging sensor of the imaging device at the time the image is captured or the barcode is scanned. For example, the camera state may include any other information that may vary with exposure time, ISO sensitivity, focal length, flash usage, light balancing, resolution or time, environmental conditions such as lighting, camera orientation or position. .. In some embodiments, one or more additional sensors may be provided to provide additional information related to the state of the imaging device.

[0050] The user device may have one or more sensors 116 on the board of the device to provide the momentary position and attitude information of the image pickup device. In some embodiments, the position and orientation information is a position sensor (eg, Global Positioning System (GPS)), an inertial sensor (eg, an accelerometer, a gyroscope, an inertial measurement unit (IMU)), an altitude sensor. It may be provided by sensors such as attitude sensors (eg, compass), pressure sensors (eg, barometers) and / or field sensors (eg, magnetic meters, electromagnetic sensors).

[0051] One or more sensors 116 are, but are not limited to, position sensors (eg, global positioning system (GPS) sensors, transmitters of mobile devices that enable position triangulation), vision sensors (eg,). For example, an image pickup device capable of detecting visible light, infrared light or ultraviolet light such as a camera), a proximity sensor (for example, an ultrasonic sensor, a rider, a flight time camera), an inertial sensor (for example, an accelerometer, a gyroscope, an inertial measurement). Can detect device (IMU)), altitude sensor, pressure sensor (eg, barometer), voice sensor (eg, microphone), time sensor (eg, clock), temperature sensor, memory usage and / or processor usage. It may include a sensor or a field sensor (eg, a magnetic meter, an electromagnetic sensor). Any suitable number and combination of sensors can be used, such as one, two, three, four, five or more sensors. Data can optionally be received from different types of sensors (eg, 2 types, 3 types, 4 types, 5 types, and more). Different types of sensors may measure different types of signals or information (eg, position, orientation, velocity, acceleration, proximity, pressure, etc.) and / or use different types of measurement techniques to obtain data. can. For example, the sensor may include any suitable combination of an active sensor (eg, a sensor that generates and measures energy from its own source) and a passive sensor (eg, a sensor that detects available energy).

[0052] Any number of sensors may be mounted and provided on the user device. Sensors may include different types of sensors or the same type of sensor. The sensors and / or any other component described herein can be housed within the housing of the device and embedded within the housing of the device or on an outer portion of the housing of the device. The housing may or may not form a liquidtight (eg, watertight or airtight) seal that separates the inside of the housing and / or the outside of the housing.

[0053] One or more sensors 116 may continuously collect information in real time or may collect information periodically. In some embodiments, the sensor can collect information at regular or irregular time intervals. The sensor frequently outputs information (eg, every minute, more often every 10 seconds, more often every 1 second, more often every 0.5 seconds, more often 0.1. Every second, more often every 0.05 seconds, more often every 0.01 seconds, more often every 0.005 seconds, more often every 0.001 seconds, more often Can be collected every 0.0005 seconds, more often every 0.0001 seconds or more often). The sensor may collect information according to a regular or irregular schedule.

[0054] The sensor can collect information according to the detected event. In some embodiments, the sensor may collect information at the beginning, completion, or any state in between of transactions that require user identification / authentication. The sensor may collect information when the user is authenticated. For example, the sensor may collect information when the user is logged in. The sensor may collect information when the image pickup device is activated to capture the image. Sensors may collect information when a user is trying to access a user account. The sensor may collect information when the user requests the completion of a transaction. The sensor may collect information when the user requests a deposit or remittance.

[0055] The sensor may collect information at a single point in time or at multiple time points. In some embodiments, the sensor may collect information over a time interval (eg, periodically, continuously, etc.). In some embodiments, the time interval is 10 seconds, 5 seconds, 3 seconds, 2 seconds, 1 second, 0.5 seconds, 0.3 seconds, 0.1 seconds, 0.05 seconds, 0.01 seconds. , 0.005 seconds, 0.001 seconds, 0.0005 seconds or 0.0001 seconds or less. Alternatively, the time interval can be greater than or equal to any of the values described herein, or can be included in the range between any two of the values described herein. ..

[0056] The state of the image pickup device may include position information related to the image pickup device. For example, the location information may include the spatial location (eg, geographic location) of the imaging device. In some embodiments, the location information may include the latitude, longitude and / or altitude of the image pickup device. In some embodiments, the location information can be represented as coordinates. The position information may include the orientation of the image pickup device. For example, the position information may include the orientation of the device with respect to one axis, two axes or three axes (eg, yaw axis, pitch axis and / or roll axis). The position information can be the posture of the image pickup device. Positional information can be determined for inertial reference systems (eg, environment, surface, gravity) and / or local reference systems.

[0057] The position information may include motion information of the image pickup apparatus. For example, the position information may include the linear velocity or linear acceleration of the device with respect to one axis, two axes or three axes. The position information may include the angular velocity or acceleration of the device centered on one axis, two axes or three axes. Positional information can be collected using one or more inertial sensors such as accelerometers, gyroscopes and / or magnetometers.

[0058] The state of the image pickup device may also include environmental information collected by the user device at the time of image capture. Environmental information may include audio information collected by the microphone of the device. Environmental information may include information collected by any other type of sensor that may collect environmental information about motion detectors, ultrasonic sensors, riders, temperature sensors, pressure sensors or devices. Environmental information may include detecting the location of the contact or hand of the user holding the device and collecting which part of the device is contacted or held by the user.

[0059] The image pickup sensor described in the present specification can be used to capture image data. The image data generated by the image pickup apparatus may include one or more images which may be a still image (eg, a photograph), a moving image (eg, a video) or an appropriate combination thereof. The image data can be multicolor (eg RGB, CMYK, HSV) or monochrome (eg grayscale, black and white, sepia). The image data can be in any image format (eg, EPS or SVG vector graph, PNG, GIF or JPEG raster graphics format, etc.). The image data used for authentication may or may not be stored in the database.

[0060] The state of the captured image may include information on the unprocessed image (eg, metadata) or data involved in image processing. In some cases, image data can be processed to extract encoded information within the region of interest. The region of interest in the captured image can have a deformed shape, indefinite brightness, resolution, and size because it is captured from a user-controlled imaging device. For example, scanned images containing physical representations such as barcodes can be analyzed or processed. The shape of the barcode can be normalized using various algorithms or methods. For example, the shape of a barcode can be first recognized by detecting edges and / or corners, normalized by inverse perspective conversion, converted to binary image data, and decoded. A large number of parameters can be generated during image processing operations (eg, skew angle removal, trimming, normalization, enhancement, filtering, etc.). In some cases, image processing may be applied to extract the identification information encoded in the barcode. In another example, a large number of parameters can be obtained from an analysis of the properties or properties of an image (eg, brightness, width, height, resolution, etc.). Details of nonce data related to images or image processing will be described later herein.

[0061] Information related to the state of the image pickup apparatus and the image data can be stored as nonce data. The nonce data may include information generated from one or more sensors and one or more processors.

[0062] In some embodiments, the nonce data may include information generated from the sensor data. In some embodiments, information from a single sensor may be stored as nonce data. Instead, information from multiple sensors may be stored as nonce data. The nonce data may include sensor information collected at a single point in time or over a time interval. The nonce data may include unprocessed sensor information or may include processed sensor information. Nonce data can be generated based on sensor information. In some embodiments, the nonce data can be derived from the sensor information or can be a hash of the sensor information. The nonce data can be derived from at least some sensor information that should not be realistically repeated. For example, the position (eg, orientation) of the imaging device is unlikely to repeat exactly with a high level of limitation. Nonce data should not be realistically repeated. Nonce data only realistically occurs in a single time. Nonce data can represent singularity values that are very likely to be generated or used only once. Therefore, any repetition of nonce data can be a signal that a replay attack may be taking place.

[0063] Nonce data can be generated as often as sensor data is collected. Instead, nonce data may be generated less frequently than sensor data is collected. In one example, sensor data may collect information continuously or frequently, while nonce data may be generated and / or stored in response to detected events. In some embodiments, all of the sensor data collected can be used to generate nonce data. Instead, some of the sensor data collected may not be used to generate nonce data.

[0064] In some embodiments, the nonce data may further include data generated by one or more processors involved in the analysis and / or processing of the image data. One or more processors may be on the board of the user device. One or more processors, such as the microprocessor of the image capture device, may be on the board of the image pickup device. In some embodiments, one or more processors may be configured to preprocess the captured image data and output the image data along with the metadata to another processor. In some embodiments, one or more processors may be configured to process captured image data, such as performing pattern recognition to extract identification information from visual tokens contained within the image data. .. Therefore, various parameters and properties of the visual token image can be generated during image processing operations and / or analysis. The parameters can be obtained during preprocessing operations such as automatic adjustment of the unprocessed image by the image capture device (eg, balance correction, gamma correction, mosaic removal, speckle removal, etc.). Parameters include physical tokens such as image segmentation, edge detection, corner detection, pattern detection, image skew angle and rotation measurements, pixel content and histogram measurements, image scaling, smoothing, morphological filters, etc. It can be acquired during an image processing operation for recognizing and / or decrypting a token. The operation may be applied to the entire image or the recognized area of interest.

[0065] The nonce data may include data related to the state of the image pickup apparatus and the state of the captured image data. Data can be collected when images of visual tokens are captured, processed and analyzed for authentication. In some embodiments, all of the collected data can be used to generate nonce data. Instead, not all of the collected data need to be used to generate nonce data.

[0066] The nonce data may relate to the data of the components of the device. For example, nonce data may include data about the stage of operation of a device or component of the device. Local data about the device or any component of the device may be collected. Local data about the device can refer to the state of the device or its components. In some examples, local data may refer to the state of the device or component that does not consider the environmental conditions around the device. Examples of components of a device may include a display, memory, processor, power supply, communication unit, sensor, housing or any other component of the device. The local state of the device may include location information such as the orientation of the device. The local state of the device may include position-independent operational data that represents how the component is operating or the conditions under which the component is operating. Local data can be collected at a single point in time, at multiple points in time in a row, or over a time interval.

[0067] In one example, local data about the device may refer to the state of the display of the device. For example, local data may include whether the display is turned on or off. Local data may include images displayed on the display. For example, the local data may include screenshots of the image on the display or may include data about the image displayed on the display. Local data may include screenshots of the display over a period of time (eg, dynamic display). Analysis of other data regarding light distribution and / or images may be collected. Calculations of the power consumed by the display at some point can be collected. In some embodiments, it may be determined that changes in the state of the display can reduce the likelihood of a replay attack. If the state change of the display is included as part of the nonce data or if the nonce data is derived based on the state of the display, the state change of the display can be reflected in the change of the nonce data. Similar applications to nonce data can be applied to any other type of data collected with respect to the device, including other local and / or environmental data described elsewhere herein.

[0068] Local data about the device may indicate the state of power supply of the device. For example, the battery status of charging (eg, percentage of remaining charge, remaining battery life, etc.) can be evaluated. The state of charge of the battery can be determined to a high degree of accuracy and / or accuracy. For example, the remaining percentage of remaining charge is about 1%, 0.5%, 0.1%, 0.05%, 0.01%, 0.005%, 0.001%, 0.0001% or 0. It can be calculated up to the range of .0000001%. Local data may also include information about battery consumption at a given point in time. Battery consumption rates can also be determined to a high degree of accuracy and / or accuracy, such as every 1 second, every 1 millisecond, or any other percentage value described for each other time unit. Local data may also include battery temperature or any other measurement of the battery.

[0069] Local data may include the temperature of any component of the device or the entire device. The temperature can be determined to a high degree of accuracy and / or accuracy. For example, the temperatures are 2 degrees Celsius, 1 degree Celsius, 0.5 degrees Celsius, 0.1 degrees Celsius, 0.05 degrees Celsius, 0.01 degrees Celsius, 0.005 degrees Celsius, 0.001 degrees Celsius, 0.001 degrees Celsius. It can be obtained within the range of 0.0005 degrees Celsius, 0.0001 degrees Celsius, 0.00005 degrees Celsius or 0.00001 degrees Celsius. The temperature of multiple components of the device can be determined. Temperature profiles can be generated for multiple components of the device. It may be extremely unlikely that the exact same temperature for a component or combination of components could be collected during different authentication events. The temperature data may also include the rate of change in temperature at a given point in time for a single component or multiple components. The same temperature and / or temperature profile can increase the likelihood of a replay attack, and / or the different temperatures and / or temperature profiles can reduce the likelihood of a replay.

[0070] In addition, the local data of the device may include information about the use of the communication unit of the device. For example, the amount of data transmitted and / or received to the outside may be collected. Information about the data content itself transmitted and / or received externally may be collected. In another example, information about the identification or type of external device or network communicating with the communication unit may be collected. Such information about the communication unit may be taken at a single point in time or over time intervals. If the data in the communication units are the same, the likelihood of a replay attack may increase, or if the data are different, the likelihood of a replay attack may decrease.

Further local data of the device may include information about one or more memory storage units. For example, the amount of stored and / or remaining memory can be determined. The amount of memory stored and / or remaining can be determined on the order of bytes or as a percentage. The distribution of the stored memory can also be obtained. For example, the level of fragmentation or how data fragmentation is stored or distributed can be determined. Exact duplication of data storage or data storage distribution between authentication events may be unlikely to be repeated. The content of the data stored in the memory storage unit may or may not be considered when determining the local data. If the data related to memory storage is the same, the likelihood of a replay attack may increase, or if the data are different, the likelihood of a replay attack may decrease.

[0072] In some embodiments, the local data of the device may include information about one or more processors of the device. For example, the processor usage level can be determined (eg, as a number or percentage). In some embodiments, data about software or applications running on the device can be obtained. You can ask for the use of processors associated with each of the software or applications. Processor usage profiles can be created based on the use of various software, applications and / or processes. Such data may be collected at a single point in time or over time intervals. If the data related to the processor is the same, the likelihood of a replay attack may increase, or if the data are different, the likelihood of a replay attack may decrease.

[0073] The set of local data of the device may include data relating to one or more sensors of the device. The data collected by the sensor itself can be used for local data. In some examples, the operating parameters of the sensor (eg, whether the sensor is on or off, whether it is collecting data, how often data is collected, the direction in which it is collected, the sensitivity of data collection, it is collected. The amount of data collected, the data itself collected) can be evaluated. In one example, if the sensor is a camera, camera operating parameters such as shooting mode, zoom information, exposure, focus, direction, light balance, resolution, and any other information about the camera may be used as local data. Data relating to a single sensor or multiple sensors may be considered. For example, sensor combinations can be considered when determining the sensor usage profile. Data related to the sensor can be collected at a single point in time or over a period of time. If the data related to the sensor is the same, the likelihood of a replay attack may increase, or if the data are different, the likelihood of a replay attack may decrease.

[0074] Nonce data may include any kind of environmental data about the equipment that can be collected. Environmental data about the device can refer to data about the environment outside the device. In some examples, environmental data may include a set of data on external conditions outside the device. Such data may be visual, thermal, audio, may include data at any location along the electromagnetic spectrum, or may include acoustic information. Environmental data can be collected at a single point in time, at multiple points in time in a row, or over a period of time.

[0075] In one example, environmental data about a device may refer to data collected by an image sensor of the device. One or more image sensors of the device may be used to collect images of the environment outside the device. The image collected by the image sensor may include an image of one or more landmark features around the device and / or an image of the user of the device or any combination thereof. Environmental data may include images captured by one or more image sensors, or may include data about images captured by one or more image sensors. Environmental data can include snapshots collected over a period of time (eg, dynamic display). Analysis of other data regarding light distribution and / or images may be collected. For example, other data regarding luminance distribution, color distribution, saturation, color tone or image may be collected and / or analyzed. Such data may be collected and / or investigated for each pixel or pixel group (eg, pixel row, pixel height). In some embodiments, it may be determined that changes in the captured image can reduce the likelihood of a replay attack. It is extremely unlikely that exactly the same image data will occur, indicating a high probability of a replay attack. When the image data is included as part of the nonce data or when the nonce data is derived based on the image data, the change in the image data can be reflected in the change in the nonce data. Similarly, in the absence of other nonce factors that may have changed, the same image data may be reflected in the unchanged nonce data. Similar applications to nonce data can be applied to any other type of data collected with respect to the device, including other local and / or environmental data described elsewhere herein.

[0076] The image sensor can be a camera used to capture a visual image around the device. Any other type of sensor can be used, such as an infrared sensor that can be used to capture thermal images around the device. The image sensor can collect information at any location along the electromagnetic spectrum and can generate a corresponding image accordingly.

[0077] In some embodiments, the image sensor may be operational with very high resolution. The image sensor is about 100 μm, 50 μm, 10 μm, 5 μm, 2 μm, 1 μm, 0.5 μm, 0.1 μm, 0.05 μm, 0.01 μm, 0.005 μm, 0.001 μm, 0.0005 μm or 0.0001 μm or more. Can have resolution. The image sensor may be capable of collecting images of 4K or higher.

[0078] In some embodiments, the sensor used to collect environmental data is a rider, sonar, radar, ultrasonic sensor, motion sensor or other sensor capable of producing a signal that can be reflected in the sensor. It may include any sensor. Such sensors, such as the presence and / or position of objects in the environment, can be used to collect information about the environment.

[0079] Another example of environmental data may relate to one or more voice sensors that may be used to collect environmental information 450. Audio information may include sounds captured from the environment. Such sounds may include noise and / or noise produced by the device itself. Audio data may include audio snapshots collected at a single point in time, or may include audio clips collected over a period of time. The period is about 10 seconds, 5 seconds, 3 seconds, 2 seconds, 1 second, 0.5 seconds, 0.1 seconds, 0.05 seconds, 0.01 seconds, 0.005 seconds, 0.001 seconds, 0. It can be less than 0.0505 seconds, 0.0001 seconds, 0.00005 seconds, 0.00001 seconds, 0.000005 seconds or 0.000001 seconds. Alternatively, the period can be greater than or equal to any of the listed values, or can fall within the range between any two of the listed values.

[0080] Analysis of audio characteristics of audio data can be collected or sought. For example, fast Fourier transform (FFT) analysis or similar type of analysis can be performed on speech data. In some embodiments, it may be determined that changes in captured audio may reduce the likelihood of a replay attack. Analysis of unprocessed audio data and / or unprocessed audio data may be provided as environmental data. In this way, an audio finger print can be generated. Voice finger prints can be expected to be specific at a particular time when data is collected. It is extremely unlikely that exactly the same audio data will occur, indicating a high probability of a replay attack. If the audio data is included as part of the nonce data or if the nonce data is derived based on the audio data, changes in the audio data may be reflected in the changes in the nonce data. Similarly, in the absence of other nonce factors that may have changed, the same audio data may be reflected in the unchanged nonce data. Similar applications to nonce data can be applied to any other type of data collected with respect to the device, including other local and / or environmental data described elsewhere herein.

[0081] In some embodiments, one or more voice sensors may be used to collect information. The voice sensor can be a microphone. The microphone can be a directional microphone or a parabolic microphone that can collect information from a wide range of directions or has a limited directional range. The microphone can be a condenser microphone, a dynamic microphone, a ribbon microphone, a carbon microphone, a piezoelectric microphone, an optical fiber microphone, a laser microphone, a liquid microphone, a MEMs microphone, or any other type of microphone. The voice sensor may be able to collect voice data with a high degree of sensitivity. In some embodiments, the voice sensor is 10 dB, 5 dB, 3 dB, 2 dB, 1 dB, 0.5 dB, 0.1 dB, 0.05 dB, 0.01 dB, 0.005 dB, 0.001 dB, 0.0005 dB, 0. Audio data can be distinguished on the order of .0001 dB, 0.00005 dB or 0.00001 dB or less. As mentioned earlier, it is highly unlikely that audio data will be repeated accurately, especially when collected by a sensitive microphone. A 100% match of allegedly collected audio for different transactions can increase the likelihood of a replay attack.

[0082] The nonce data may be related to the checksum function. For example, a checksum function can be used to derive a checksum value using any type of data input. The checksum value can be nonce data. Checksum values can vary significantly even if the input values differ only slightly. Any kind of checksum function known or later developed can be used. For example, the checksum can use a parity check such as a horizontal parity check. Modular sums can be used in some examples. Some checksums, such as Fletcher's checksum, Adler-32 or Cyclic Redundancy Check (CRC), may be position dependent. In some examples, the checksum value can be used as nonce data. The checksum function can be an existing checksum function and / or can be utilized by the system to detect errors that may occur during transmission or storage. Checksum values can be further utilized to generate nonce data in addition to the above purposes. The checksum value can be small size data derived from a block of digital data (eg, image data), which can reduce the memory or data transmission bandwidth required for authentication.

[0083] For example, as shown in FIG. 10A, sensor data can be applied to a checksum function to obtain a checksum value. Data from any of the sensors described elsewhere herein, such as position sensors, image sensors, voice sensors, vibration sensors, motion sensors, infrared sensors or any other type of sensor, are subjected to a checksum function. It can bring a checksum value. The checksum value can be used as nonce data. For example, if the checksum values are the same, it can be determined that the sensor data are the same. As described elsewhere herein, such a match can affect the likelihood of a replay attack.

[0084] Similarly, as shown in FIG. 10B, the image data can be subjected to a checksum function to obtain a checksum value. Data derived from the image itself (eg, an image of a user's ID card, a self-portrait image, etc.) or various parameters related to the image can be applied to a checksum function to obtain a checksum value. Optionally, the checksum value can be used as nonce data. For example, if the checksum values are the same, it can be determined that the image data is the same. As described elsewhere herein, such a match can affect the likelihood of a replay attack.

[0085] Further, FIG. 10C shows that the data of the components of the device can be applied to the checksum function to obtain the checksum value. Checksum values can be derived using any type of data, including local or operational data or environmental data. In some examples, the checksum value can be used as nonce data. For example, if the checksum values are the same, it can be determined that the data of the components of the device are the same. As described elsewhere herein, such a match can affect the likelihood of a replay attack.

[0086] In some embodiments, the checksum value can be a nonce factor. The checksum value can form a nonce factor that can form part of the nonce data or can be used to derive the nonce data.

[0087] In some examples, the input to the checksum can be a nonce factor or nonce data. As described elsewhere herein, the nonce factor or nonce value can be obtained from one or more data sources. The nonce factor or nonce data can be further applied to the checksum function. The possibility of a replay attack can be determined by comparing the checksum values.

[0088] Checksum values can be generated on the board of the device. For example, the checksum value can be generated using one or more processors in the device. The checksum value can be stored in one or more memory storage units of the device. The checksum value may be transmitted to an external device or network using the communication unit. Instead, the checksum value can be generated off the board of the device. Data from a data source such as a sensor or processor may or may not be stored in memory prior to transmission. Data from data sources can be used in external devices or networks to generate checksum data.

[0089] Nonce data can be generated on the board of the device. For example, nonce data can be generated using one or more processors in the device. The nonce data can be stored in one or more memory storage units of the device. The nonce data may be transmitted to an external device or network using a communication unit. Instead, nonce data can be generated off-board of the device. Data from one or more sensors and one or more processors on the board of the user device may be transmitted to an external device or network using a communication unit. Data from sensors and processors may or may not be stored in memory prior to transmission. Data from sensors and processors can be used in external devices or networks to generate nonce data.

[0090] The checksum data can optionally be derived in the same device that produces the nonce data, or can be derived in a device different from the device that produces the nonce data. For example, both checksum and nonce data can be derived locally on the device. Instead, checksums can be generated on the device, while nonce data is derived on the external device or network. In another example, the nonce data can be generated on the device, while the checksum value is derived on the external device or network. In some examples, both checksum values and nonce data can be generated off-board of the device in an external device or network.

[0091] FIG. 2 shows an example of using the user device 203 to capture the physical token 207 for authentication according to an embodiment of the invention. The user device 203 can generate both identification data and nonce data by capturing the image of the physical token 207 and can be used to use that data for authentication. In some cases, the user device can be used to capture a selfie image or video instead of or in addition to capturing a physical token. Nonce data generated during the capture of selfie images can also be used for authentication or to detect replay attacks. The nonce data generated during the capture of the selfie image can be used to detect replay attacks in connection with the face recognition based authentication process. Alternatively or additionally, the nonce data generated during the capture of the selfie image can be used in combination with the metadata generated during the scan of the physical token. Details regarding the use of self-portrait images will be described later herein.

The identification data may include information used to authenticate or verify the identity of the user. The identification data may include personal information such as a name, birthday, address, nationality, etc. representing the user's identification. The identification data may include product information such as instructions for identifying the product or service, purchase options, service provider information, and the like. The identification data may include any kind of information that can uniquely identify a user, service, transaction, etc. The identification data can include information related to the same user, the same service or the same transaction. In some embodiments, the information or identifier may be a ciphertext previously encrypted in the identification data. A private key or password may be required to decrypt the information. In other embodiments, the identification data can be plaintext, which is unencrypted data.

[0093] In some embodiments, the identification data may be encoded in the physical token 207. The physical token can be a visual graphical element that can be scanned by a suitable device (eg, bar code reader, optical scanner, camera) or can be machine readable. The visual graphical element can be in any form that can be captured and / or displayed on the device, such as barcodes, texts, pictures, sequences thereof, and the like. The visual graphical element can be a two-dimensional bar code such as PDF417, Aztec, MaxiCode and QR code. Visual graphical elements include Interleaved 2/5, Industrial 2/5, Code39, Code39 Extended, Codabar, Code11, Code128, Code128 Extended, EAN / UCC128, UPC-E, UPC-A, EAN-8, EAN-13, It can be a one-dimensional barcode such as Code93, Code93 Extended, DataBar Omnidirectional (RSS-14), DataBar Truncated (RSS-14 Truncated), DataBar Limited (RSS Limited), DataBar Stacked, DataBar Expanded, DataBar Expanded Stacked. Barcodes can encode various types of information in any type of suitable format such as binary, alphanumerical or ASCII, and the code can be based on any standard. Visual graphical elements can have various storage capacities and indefinite physical sizes that can encode a certain amount of data. In some embodiments, the barcode may comply with a known standard readable by a standard barcode reader. In other embodiments, the barcode may be under exclusive rights, whereby such a barcode can only be read by an authenticated application provided by an authentication system and the application is on the user device. Authenticated that it can be done in. In some examples, only an authentication system or authentication application can encrypt / decrypt barcodes.

[0094] FIG. 2 shows an exemplary physical element 205 having the physical token 207. In some embodiments, the physical token 207 can be a visual graphical code on the physical element 205 held by the user. Physical element 205 is a card (ID card, driver's license, payment card, library card, login card, etc.) issued or provided by an entity or service provider, documents (passport, legal documents, health care records, etc.), etc. obtain. In some cases, the physical element can be a card, paper document or other form of credential issued by an authoritative entity such as a government, DMV, federal agency. In some embodiments, the physical element can be an individual citizenship certificate such as a social security card, passport, driver's license, e-passport, birth certificate, employee identification card. In addition, physical elements that may contain records, electronic identification information, etc. in the database may be used to establish user identification.

[0095] In some embodiments, the physical token 207 may be a visual graphical code that may be displayed on the display device. A display device is a computer (eg, a laptop computer, etc.) that requires user authentication or verification to perform a session or transaction using the display device to complete a transaction performed on a server (ie, a service provider). It can be a desktop computer), a mobile device (eg, a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a vending machine, or the like. The display device can optionally be portable. The display device can be handheld.

[0096] The user device 203 may include an image pickup device 200 used to capture the image data of the physical token 207. The image pickup device may be the same image pickup device as shown in FIG. As described elsewhere herein, the image data can be still image data (eg, photographs) or moving image data (eg, video). In some embodiments, the captured photo can be displayed on the display 202 of the user device. In some embodiments, the user may be allowed to visualize the barcode on the display 202 in real time without capturing a picture of the barcode. In some cases, the display can let the user know if a valid image has been captured. Poor quality images can be invalid for use in decryption and authentication. Factors such as lighting, focus, and stability can affect image quality. In some embodiments, the display may provide a message indicating a read failure if the physical token cannot be decrypted within a predetermined time. In some embodiments, the user may be prompted to adjust the distance, orientation or angle between the target and the user device in order to capture the entire barcode area.

[0097] In other embodiments, all physical tokens may be required for authentication. In other embodiments, a portion of the barcode area may be sufficient for authentication. For example, 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90% of physical tokens may be captured in the image data for authentication and generation of nonce data.

[0098] In some embodiments, the photograph of the barcode 207 can be acquired and stored on the memory unit of the user device 203 for further image processing and decoding. Instead, the image pickup device 200 can scan the barcode in real time without capturing a picture of the barcode. In this embodiment, the image pickup apparatus 200 can constantly acquire an image of the barcode 207 and store it in memory. Each of those images will be processed later until the barcode is correctly decoded. When the barcode 207 is decoded, the image pickup apparatus 200 can stop the acquisition of the image of the barcode.

[0099] In some cases, captured image data can be processed to extract identification information for authentication. The physical token 207 shown in FIG. 2 may be a region of interest containing black and white modules that encode the identification information. The barcode area can be any shape such as a rectangle, a square, a triangle, a circle, an ellipse, and the like. The area of interest of the barcode may or may not have boundaries. For example, the region of interest may be a rectangular region containing a PDF417 code, which may encode user identification information such as name, address, birthday, and the like. In alternative cases, the identification information may not be provided by the captured image data. For example, the identification information can be a device ID or user ID associated with the user device or authentication application.

[0100] In some embodiments, the coded identification information may have been encoded in the past, and an encryption key may be required to decrypt the ciphertext. For example, the PDF417 code on a driver's license can be decrypted by a standard reader, but the decrypted identification information may have been previously encrypted by the issuer, thereby decrypting the identification data. Key and cryptographic algorithms may be required. In some cases, only the authoritative entity or a particular service provider may retain the encryption key and method. In other embodiments, the user device may hold the encryption key and method. Keys and methods can be standard. For example, the data can be encrypted using 1024-bit polymorphic encryption or, depending on export control, the AES256-bit encryption method. Further, encryption can be performed using a remote key (seed) or a local key (seed). Alternative encryption methods such as SHA256, AES, Blowfish, RSA, etc. may be used as understood by those of skill in the art.

[0101] In some embodiments, physical tokens can be processed and decrypted to obtain identification data. Physical tokens are from images captured in any orientation, size, lighting conditions, etc. that can cause blurry images, noisy images, skewed images, scaled images, distorted images, etc. Can be read. During the image processing process, various properties of image data, including physical tokens, can be analyzed. The captured image data and the characteristics of the image pickup device can be used to generate the nonce data.

[0102] In some embodiments, a selfie image or video clip can be taken to authenticate the user. FIG. 2A shows an example of a user device 203 for capturing a self-portrait image 211 for authentication according to an embodiment of the present invention.

[0103] The user device 203 and the image pickup device 210 may be the same as the device shown in FIG. The user device used to capture the self-portrait image may be the same device used to perform the transaction or other function described elsewhere herein. User devices may communicate with devices used to perform the transactions or other functions described elsewhere herein. The user device can include a camera that can be used to capture a selfie image. Selfie images may include visible light images, IR images or other types of images.

[0104] In some embodiments, a photograph of the user, especially the face portion, can be acquired and stored on the memory unit of the user device 203 for further image processing and face recognition. Alternatively or additionally, the user's photo may be stored in a database accessed by a server that communicates with the user device. Image processing and face recognition can be performed by the user device and / or the server. In some cases, the imaging device 210 can scan the user in real time without capturing the user's picture. In one embodiment, the image pickup device 210 can constantly acquire an image of the user and store it in memory. Each of those images will be processed later until biometrics of the user's face are detected. When the user's face is detected, the image pickup apparatus 210 can stop the acquisition of the user's image. In some cases, the user may be prompted to take a selfie image. For example, the user may be asked for permission to scan the face. Upon receiving a user command indicating permission to take a selfie image or a face scan, the camera can be automatically activated to scan the face. Alternatively, user input may not be required for performing a face scan or taking a selfie image. In some cases, the user can be notified if the selfie image is invalid for further processing. For example, the user can be notified about the specific reason why the self-portrait image is invalid (for example, the image quality is not good enough to detect a face, the authenticated user is not recognized, etc.). Instead, the user does not have to be informed about the validity of the selfie image.

[0105] In some cases, the captured image data can be processed to extract features / features / marks of the user's face for authentication. The image can be a still image or a series of images (“live image”). Selfie images can include still images, video clips, live images or any other type of image. The self-portrait image may include at least a portion of the user within the image. For example, at least some of the user's face, head, silhouette, body, and accessories may be visible in the image. The self-portrait image may include at least a portion of the user's face. The self-portrait image may optionally include the entire user's face or at least a sufficient portion of the user's face useful for face recognition. In some examples, minimal data points on the face or a set of specific facial features may be included in the selfie image. In some cases, image processing related information for extracting facial features / features / landmarks may be used to generate nonce data that can be used to detect replay attacks.

[0106] FIG. 3 shows an example of data that can be used as nonce data generated during image capture and processing according to an embodiment of the present invention. In some embodiments, the data may relate to the state of the imaging device. Part A shows an example of local data about an image pickup device that can be collected during image capture. Local data about the image pickup device can refer to the state of the component of the image pickup device such as the image pickup device or the image pickup sensor, the optical element, and the like. The local data of the image pickup apparatus may include location information such as the orientation of the apparatus and the geographical position. The local data of the image pickup apparatus may include a time stamp such as the time when the image is captured, the time when the image is modified, and the like. Local data of the image pickup device may include operating parameters based on events such as focal length, ISO, frame rate, shutter speed and the like. In some embodiments, local data may be collected from one or more sensors of the user device such as GPS, IMU, accelerometer and barometer described elsewhere herein.

[0107] In some embodiments, local data about the image pickup device can be obtained from image metadata. The metadata can be data that is automatically added to the photo. The metadata may include variable data including technical information about the image and its acquisition method, such as exposure settings, acquisition time, GPS position information and camera model. In some embodiments, the metadata is generated by the microprocessor on the board of the imaging device.

[0108] Local data of the imaging device may include operating parameters. In some embodiments, the operating parameters can be event-based parameters. For example, the exposure time can vary based on local illumination light conditions. The focal length of the image pickup device can be automatically changed based on the distance between the physical token and the image pickup device. The ISO, shutter, and aperture speed can be automatically adjusted according to a predetermined algorithm to deal with the changing environment and the object to be imaged.

[0109] One or more processors on the board of the imaging device can be provided that can facilitate the collection of operating parameters for the imaging device. For example, an imaging device can have a first set of operating parameters at a first time point of capture of a physical token and a different set of operating parameters at a second time point of capturing the same physical token. .. As described above, the operating parameters can be automatically adjusted according to a predetermined algorithm in order to cope with a highly variable environment.

[0110] The local data of the image pickup apparatus may include position information. In some embodiments, the location information may include the latitude, longitude and / or altitude of the device. In some embodiments, location information can be represented as coordinates. The location information may include the orientation of the device. For example, the position information may include the orientation of the device with respect to one axis, two axes or three axes (eg, yaw axis, pitch axis and / or roll axis). The position information can be the attitude of the device. Positional information can be determined for inertial reference systems (eg, environment, surface, gravity) and / or local reference systems.

[0111] One or more sensors can be provided that can facilitate the collection of position information about the imaging device. For example, the device may be oriented differently over time. For example, with respect to a static frame of reference, the device can have different orientations. The angle between the axes can change over time. As described above, position information (eg, angle information, spatial position information) can be determined to a high degree of accuracy and / or accuracy. The orientation of the device can be evaluated over one axis, two axes or three axes. The spatial position of the device can be evaluated along one axis, two axes or three axes.

[0112] Local data of the image pickup device may also include time stamps such as the time the image is captured, the time the image is preprocessed by the processor on the board of the image pickup device, the time the image is stored and / or output. ..

[0113] Authentication events can occur at various times. The user can authenticate and / or participate in the transaction at various times. The same imaging device may be used to capture the same physical token by the same user, but they may have exactly the same local data (eg, operating parameters, position, orientation and / or time stamp) of the imaging device. Very unlikely to have. At least some minor fluctuations can be expected in the local data between authentication events. Therefore, if the local data of the image pickup device taken in various authentication events are exactly the same, it is possible that a replay attack has been performed. For example, a fraudster may have previously recorded authentication events (eg, past transactions, user authentication, account access) that include local data from the imaging device and replayed past authentication events. In one example, during the first authentication event, the local data of the imaging device can be read as shown in Part A. If, during the second authentication event, the local data on the device is read to be exactly the same, there is little chance of such a match and it may indicate a replay attack. Especially when the device is a mobile device or a portable device, the information of the image pickup device is likely to change. Even if the device is on a surface during an authentication event, the user's dialogue with the device can cause some changes in imaging conditions (eg, focal length, line of sight, etc.). Environmental conditions such as lighting can cause some parameter changes (eg ISO speed, aperture speed, shutter speed, exposure time) even if the user does not come into direct contact with the device.

[0114] Part B shows that an example of data can be collected from image processing and used as nonce data. The data collected may be related to the state of the image data. The data collected may be related to various properties of the image data. In some embodiments, the captured image data 301 may include a region of interest 303. The region of interest can be a barcode region containing a pattern that encodes the identification information. The region of interest can be the same as shown in FIG. In some embodiments, image data can be processed to decode the information. For example, the captured image data can be deformed or distorted, and in order to decode the barcode, the captured image data can be rotated, skewed, converted to a binary image, cropped, denoised, resized. , It may be necessary to perform normalization such as alignment. Various operations can generate characteristic data that can vary with respect to the various images captured.

[0115] For example, as shown in Part B, the barcode area 303 rotated with respect to the scan area 302 may be captured. The angle between the image coordinates 305 and the barcode coordinates 307 (ie, the orientation of the barcode with respect to the image frame) can change each time the user takes an image. For example, the image data 301 captured in the first authentication event is shown in scenario B-1, and the coordinates of the upper left corner of the barcode area can be detected as [x, y] 309. The same graphical code can be captured in the second authentication event and the image data 311 can be shown as in scenario B-2. The coordinates of the upper left corner of the same graphical code can be [x', y'] 313, which is different from the coordinates of the first authentication event.

[0116] Various properties or properties of the image data (eg, degree of skew angle of barcode region, rotation / direction angle, width, height) can vary between authentication events. For example, the distance between the imager and the target can lead to a wide range of possible sizes (magnifications) that the barcode can have on a fixed size image sensor. In another example, taking an image of a barcode at an angle changes the apparent shape (degree of skew angle) of the barcode for the viewer. Barcode B-1, which has a rectangular shape when viewed from the front, may look like a trapezoidal (or irregular quadrilateral) B-2 when viewed at an angle. When viewed from the side or at an angle, the position and addressing of image pixels in barcodes changes dramatically.

[0117] The captured image data can be processed to decode the authentication information. In some embodiments, the data generated during image processing can be used as nonce data. Nonce data can be generated from various properties of captured image data obtained from image processing. Various characteristics of the captured image data, such as the coordinates of the corners of the detected barcode area, the position of the center of gravity of the captured image, the size of the related pattern, the degree of skew angle, and its orientation, can be processed without additional calculation / operation. Can be generated in. For example, when processing image data for analysis and aligning barcode areas, angles can be calculated and recorded. The coordinates (x, y) 309 of the corners of the barcode area with respect to the coordinates of the image can also be detected for pattern recognition. Other characteristics such as height, width and histogram of the barcode area can also be analyzed during image processing and can be used as nonce data.

[0118] In another example, characteristic data may be generated from preprocessing. For example, the image data can be automatically corrected with respect to the white balance. The brightness of the component RGB colors can be adjusted to render a particular color correctly. Therefore, the brightness can be analyzed during the process and used as nonce data.

[0119] In addition, characteristic data can be generated from the decoding process. For example, algorithms and methods can be implemented to address variations in brightness and contrast in the captured image data of barcodes. This can be done by using globally and locally adapted image processing operations (eg, thresholding, filtering, etc.). In another example, a pattern recognition technique can be performed to recognize a barcode pattern. During this process, properties related to some of the patterns relative to the coordinates of the image can be collected and used as nonce data. For example, the coordinates or size of the first bar pattern recognized in the denormalized image can be recorded and used as nonce data.

[0120] In some embodiments, when self-portrait image data is used for authentication, data related to the state of the imager to generate nonce data, and / or a face detection process, and / or face recognition. Characteristic data generated from the process can be used. In some embodiments, the characteristics of the self-portrait image data are as follows: (i) one or more parameters brought about during image processing, (ii) one or more properties of unprocessed image data, and: (Iii) It may contain at least one of one or more properties of the processed image data. Characteristic data can be generated during the face detection process where the captured face image data is processed to identify the face. FIG. 3A shows an example of data that can be used as nonce data generated during capture and processing of user image data according to an embodiment of the present invention.

[0121] In some embodiments, the data may relate to the state of the imaging device. In some cases, the data regarding the state of the image pickup device for taking a self-portrait image may be similar to the data created during scanning of the ID document described in FIG. FIG. 3A shows an example of local data 340 with respect to an image pickup device that may be collected during the capture of a selfie image. Local data about the image pickup device can refer to the state of the component of the image pickup device such as the image pickup device or the image pickup sensor, the optical element, and the like. The local data of the image pickup apparatus may include location information such as the orientation of the apparatus and the geographical position. The local data of the image pickup apparatus may include a time stamp such as the time when the image is captured, the time when the image is modified, and the like. Local data of the image pickup device may include operating parameters based on events such as focal length, ISO, frame rate, shutter speed and the like. In some embodiments, local data may be collected from one or more sensors of the user device such as GPS, IMU, accelerometer and barometer described elsewhere herein.

[0122] In some embodiments, local data about the image pickup device can be obtained from image metadata. The metadata can be data that is automatically added to the photo. The metadata may include variable data including technical information about the image and its acquisition method, such as exposure settings, acquisition time, GPS position information and camera model. In some embodiments, the metadata is generated by the microprocessor on the board of the imaging device.

[0123] Local data of the imaging device may include operating parameters. In some embodiments, the operating parameters can be event-based parameters. For example, the exposure time can vary based on local illumination light conditions. The focal length of the image pickup device can be automatically changed based on the distance between the physical token and the image pickup device. The ISO, shutter, and aperture speed can be automatically adjusted according to a predetermined algorithm to deal with the changing environment and the object to be imaged.

[0124] One or more processors on the board of the imaging device can be provided that can facilitate the collection of operating parameters for the imaging device. For example, an image pickup device may have a first set of operating parameters at a first time point of capturing a selfie image, and a different set of operating parameters at a second time point of capturing a self-portrait image of the same user. Can have. As described above, the operating parameters can be automatically adjusted according to a predetermined algorithm to cope with the highly variable environment.

[0125] The local data of the image pickup apparatus may include position information. In some embodiments, the location information may include the latitude, longitude and / or altitude of the device. In some embodiments, location information can be represented as coordinates. The location information may include the orientation of the device. For example, the position information may include the orientation of the device with respect to one axis, two axes or three axes (eg, yaw axis, pitch axis and / or roll axis). The position information can be the attitude of the device. Positional information can be determined for inertial reference systems (eg, environment, surface, gravity) and / or local reference systems.

[0126] One or more sensors can be provided that can facilitate the collection of position information about the imaging device. For example, the device may be oriented differently over time. For example, with respect to a static frame of reference, the device can have different orientations. The angle between the axes can change over time. As described above, position information (eg, angle information, spatial position information) can be determined to a high degree of accuracy and / or accuracy. The orientation of the device can be evaluated over one axis, two axes or three axes. The spatial position of the device can be evaluated along one axis, two axes or three axes.

[0127] Local data of the image pickup device may also include time stamps such as the time the image is captured, the time the image is preprocessed by the processor on the board of the image pickup device, the time the image is stored and / or output. ..

[0128] Authentication events can occur at various time points. The user can authenticate and / or participate in the transaction at various times. The same imager may be used to capture a selfie image by the same user, but they may have exactly the same local data (eg, motion parameters, position, orientation and / or time stamp) of the imager. Very unlikely to have. At least some minor fluctuations can be expected in the local data between authentication events. Therefore, if the local data of the image pickup device taken in various authentication events are exactly the same, it is possible that a replay attack has been performed. For example, a fraudster may have previously recorded authentication events (eg, past transactions, user authentication, account access) that include local data from the imaging device and replayed past authentication events. In one example, during the first authentication event, the local data 340 of the imaging device can be read as shown in FIG. 3A. If, during the second authentication event, the local data on the device is read to be exactly the same, there is little chance of such a match and it may indicate a replay attack. Especially when the device is a mobile device or a portable device, the information of the image pickup device is likely to change. Even if the device is on a surface during an authentication event, the user's dialogue with the device can cause some changes in imaging conditions (eg, focal length, line of sight, etc.). Environmental conditions such as lighting can cause changes in some parameters (eg, ISO speed, aperture speed, shutter speed, exposure time) even if the user does not come into direct contact with the device.

[0129] One or more parameters can be obtained during preprocessing operations such as automatic adjustment of unprocessed images by the image capture device (eg, balance correction, gamma correction, mosaic removal, speckle removal, etc.). Various image processing or computer vision techniques can be used to extract faces from images. Parameters include image segmentation, edge detection, corner detection, pattern detection, image skew angle and rotation measurements, pixel content and histogram measurements, image scaling, smoothing, morphological filters, etc. from facial images. Can be obtained during an image processing operation to extract a face. In another example, the image can be normalized, which rotates and alters the image to remove any residual artifacts that may or may not be related to facial or active gestures. May include doubling or modifying. Such artifacts may include, for example, excessive rotational differences, excessive scaling differences and subject blurring. Such parameters are very unlikely to be the same in different image processing events. One or more properties of the unprocessed and processed images, such as brightness, width, height, resolution, etc., can also be used to generate nonce data.

[0130] For example, as shown in FIG. 3A, the face image 323 rotated with respect to the scan area 320 can be captured. The angle between the image coordinates 327 and the face coordinates 325 (ie, the orientation of the face with respect to the image frame) can change each time the user takes a selfie image. In another example, in the first authentication event C-1, the coordinates of the face (eg, the center of the face) may be different from the coordinates [x', x'] 331 of the second authentication event C-2 [x]. , Y] 321 can be detected.

[0131] Information generated during the face recognition process can also be used as nonce data. With the face image already extracted, cropped, resized, and usually grayscaled, various face recognition algorithms can be used to find the characteristics that best represent the image. Any suitable facial recognition algorithm (eg, scale invariant feature conversion, fisherfaces, local binary patterns histograms, eigenfaces, speed up) to compare the input facial image to the facial image related to the user requesting authentication robust features etc.) can be used. Similarly, one or more parameters created during the face recognition process can be stored and used to generate nonce data. For example, if scale-invariant feature transformations are used to transform an image into multiple feature vectors, it collects transformation parameters such as translation, scaling, rotation, lighting changes, and local geometric distortion of the image. It can be used to generate nonce data.

[0132] Various characteristic data related to the unprocessed image generated during the image processing can be used as nonce data. Data can be collected each time a physical token or selfie image is captured and processed to decode / extract the identification information. In some embodiments, the data can be collected without image processing operations. Without alternating image data, the data can be generated by any analysis described elsewhere herein. Since the physical token can be captured for the authentication event, the data generated by processing the image data of the physical token can be automatically collected and used as nonce data.

[0133] Data relating to the state of the image pickup device and the state of the captured image data can be used as nonce data for an authentication event. Authentication events can occur at various times. The user can authenticate and / or participate in the transaction at various times. The same imaging device may be used to capture the same physical token by the same user, but they may be the exact same data about the image and / or the exact same data generated from the image processing (eg, the same data). Skew angle, angle of rotation, histogram, brightness, etc.) are extremely unlikely to have. At least some minor fluctuations can be expected in the data between authentication events. Therefore, if the image processing data or the unprocessed image data taken in different authentication events are exactly the same, it is possible that a replay attack has been performed. For example, a fraudster may have recorded authentication events (eg, past transactions, user authentication, account access) containing image state data in the past and replayed past authentication events. Especially when the device is a mobile device or a portable device, the image data information is likely to change.

[0134] Even if the device is on a surface during an authentication event, the user's dialogue with the image pickup device can cause some changes in imaging conditions such as focal length, viewing angle, and constancy. For example, the distance between the imager and the target can lead to a wide range of possible sizes (magnifications) that the barcode can have on a fixed size image sensor. In another example, taking an image of a barcode at an angle changes the apparent shape (degree of skew angle) of the barcode to the viewer.

[0135] Environmental conditions such as lighting can cause some variable changes (eg, noise, brightness, white balance, etc.) even if the user does not come into direct contact with the device. For example, the image pickup device may utilize only ambient light for illumination during acquisition of image data. Very variable ambient light can cause automatic adjustment of various imaging device parameters. Highly variable ambient light can also result in shadows, subtle differences over barcode length, overexposure, underexposure and similar characteristic changes in captured image data.

[0136] Therefore, an authentication event such as a user authentication process or a transaction can be evaluated for the possibility of falsification or fraud. If the information in the imager and image data does not show an increased likelihood of fraud, the user's identification can be verified and / or the transaction can be authenticated.

[0137] FIG. 4 shows an example of how nonce data can be generated or stored. Any description herein of nonce data may apply to any kind of singularity value. Any description of nonce data may apply to various device measurements, indicators or parameters that may be unlikely to be repeated. Any description of the nonce factor may apply to various device measurements, indicators or parameters that may be unlikely to be repeated. The nonce data may contain one or more nonce factors or may be derived from such nonce factors.

[0138] One or more nonce factors (eg, nonce factor 1 403, nonce factor 2 405, nonce factor 3 407 ...) can be used to form a set of nonce data 401. The nonce factor may include various types of data collected with respect to the state of the image pickup device and / or the state of the captured image data. The nonce factor may include different types of data related to different characteristics of the imager and captured image data. The nonce factor may include data from various sensors on the user device. The nonce factor can include various types of data collected regarding the state of the user device. The nonce factor can be taken at a single time point, at multiple time points, or over a time interval, respectively. Each of the nonce factors can be from different time points or from matching and / or overlapping times. Each of the nonce factors may include data collected from different sensors or different types of sensors in the device. Alternatively, two or more nonce factors may be collected from the same sensor or the same type of sensor. In some examples, all nonce factors may be collected from the same sensor or the same type of sensor.

[0139] In one example, the nonce data 401 can be derived from a single nonce factor. In some embodiments, a single nonce factor can be information related to a characteristic group. For example, a single nonce factor can be processed data related to the barcode area for an image frame. In this case, a single nonce factor may include a set of characteristics for the barcode region, such as the coordinates of the corners of the barcode region, the angle of rotation, the center of gravity, the width and the height. In another example, a single nonce factor can be the raw position data of the imager, so a single nonce factor can include a set of characteristics such as attitude, latitude, etc. In another example, the single nonce factor can be information related to the operating parameters of the imaging sensor, such as ISO speed, exposure time or any other type of data described elsewhere herein. A single nonce factor can contain any number of characteristic data. The nonce data can be unprocessed data read directly from the sensor, or can be derived or processed based on the unprocessed data. If the information about the characteristic group is the same between the authentication events, the nonce data can also be the same between the authentication events.

[0140] As shown in scenario A, nonce data can be derived from multiple nonce factors. For example, the first nonce factor may include image pickup device data and the second nonce factor may include image characteristic data. If the image pickup device data and the image characteristic data are the same between the authentication events, the nonce data can also be the same between the authentication events. If both the image pickup device data and the image characteristic data are different between the authentication events, the nonce data can be different between the authentication events. If at least one of the image pickup device data and the image characteristic data is different between the authentication events, the nonce data may be different between the authentication events.

[0141] If at least one nonce factor of a plurality of nonce factors differs between authentication events, the nonce data may reflect the difference and may differ between authentication events. In some examples, nonce data can differ between authentication events, even if a single nonce factor differs between authentication events. For example, each of the nonce factors may need to be 100% matched for the nonce data to be 100% matched between authentication events. This is especially true when the nonce data is derived from multiple nonce factors. For example, nonce data can be generated based on an algorithm that considers the nonce factor. The nonce data can be a hash of various nonce factors. The nonce data may contain values or strings that can be derived based on various nonce factors. In some examples, the distinction information for each of the nonce factors does not have to be determined from the nonce data. For example, the separate nonce factors may or may not be derivable from the nonce data. Alternatively, the distinction information for each of the nonce factors can be determined from the nonce data. For example, the separate nonce factors may or may not be derivable from the nonce data.

[0142] As shown in scenario B, the nonce data 411 may include a set of a plurality of nonce factors. For example, the first nonce factor may include image pickup device data and the second nonce factor may include image characteristic data. If the image pickup device data and the image characteristic data are the same between the authentication events, the nonce data can also be the same between the authentication events. If both the image pickup device data and the image characteristic data are different between the authentication events, the nonce data can be different between the authentication events. If at least one of the image pickup device data and the image characteristic data is different between the authentication events, the nonce data may be different between the authentication events. However, it may be possible to distinguish which set of nonce factors is different between authentication events and which is different.

[0143] If at least one nonce factor of a plurality of nonce factors differs between authentication events, the nonce data may reflect the difference and may differ between authentication events. In some examples, nonce data can differ between authentication events, even if a single nonce factor differs between authentication events. For example, each of the nonce factors may need to be 100% matched for the nonce data to be 100% matched between authentication events. However, each of the nonce factors may be distinguishable, so it is possible to clarify which nonce factor is a match and which nonce factor is a mismatch. For example, the nonce data can simply be a set of various nonce factors, or various nonce factors can be added together. In some examples, the distinguishing information for each of the nonce factors can be determined from the nonce data. For example, separate nonce factors can be derived or separated from the nonce data. Alternatively, the distinction information for each of the nonce factors can be determined from the nonce data. For example, the separate nonce factors may or may not be derivable from the nonce data.

[0144] Allowing the various nonce factors to be individually distinguished can advantageously allow for even better particle size in determining if a replay attack is taking place. For example, different nonce factors can be weighted differently. For example, a nonce factor that is more likely to differ between authentication events can be weighted more than a nonce factor that may be less likely to differ between authentication events. In one example, the barcode area orientation and coordinate data may be very unlikely to be the same between authentication events. However, the state of the imager may be a factor that is more likely to repeat, as there may be some variation in the state of the imager (eg, exposure time, ISO speed, etc.). In that case, more weight can be given to the data of the orientation and coordinates of the barcode area. Weighting can be taken into account during the evaluation of replay attacks.

[0145] Looking at individual factors can be useful when there may only be certain data pieces that may be recorded and / or replayed. For example, in some embodiments, all data about physical tokens may be recorded and replayed during a replay attack. In such a scenario, any deviation in any of the factors can reduce the likelihood of a replay attack. In other embodiments, only selected data about physical tokens can be recorded and replayed during a replay attack. For example, only image characteristic data may be recorded and replayed, while data relating to the state of the image pickup device is not replayed. In such a scenario, a 100% match of one of the factors (eg, the orientation of the barcode area, the degree of skew angle) may be sufficient to provide a likelihood that a replay attack has taken place. In some embodiments, the systems and methods provided herein can take into account how nonce data is collected and / or considered. If the nonce data is collected in such a way that any replay automatically combines all nonce factors, any deviation in the nonce data may be sufficient to indicate that a replay attack is unlikely. If the nonce data is collected in a way that separate nonce factors can be separated and / or provided separately, a 100% match of the nonce factors, especially the nonce factor that is unlikely to be repeated, is likely to be a high replay attack. It can be enough to show sex.

[0146] Various individual nonce factors can be considered (eg, as shown in scenario B) in determining if a replay attack has taken place. Instead, only overall nonce data (eg, as shown in scenario A) can be considered and any degree of difference can reduce the likelihood of a replay attack. In some examples, the extent of the difference can be considered when determining the likelihood of a replay attack. For example, if all nonce factors are the same, there is a high probability of a replay attack. If a single nonce factor is the same and repeatability is possible, a moderate probability of a replay attack can be provided, and if none of the nonce factors are the same, a low probability of a replay attack is provided. obtain.

[0147] FIG. 5 shows an example of how data can be stored for various transactions according to an embodiment of the invention. According to embodiments of the invention, the data may be used to identify users and / or fraudulent transactions. Transactions may be made as previously described elsewhere herein.

[0148] The data may be historical data collected from one or more authentication events, such as one or more transactions. Historical data can be stored together in a single memory unit or distributed across multiple memory units. Data distributed across multiple memory units may or may not be accessible at the same time. Historical data may include data about a single user or data from multiple users. Data from multiple users can all be stored together or stored separately from each other. Historical data may include data collected from a single user device or multiple user devices. Data from multiple user devices can all be stored together or stored separately from each other. In some examples, a single user device may be provided for a single user. Alternatively, multiple users may use a single user device or one user may use multiple user devices when performing an authentication event.

[0149] The stored data may include information such as transaction ID 501 and / or transaction related data. Any discussion herein referring to a transaction may refer to any kind of authentication event. For example, any discussion herein about a transaction may apply to any authentication and / or access to a user's account.

[0150] For example, the transaction ID 501, such as TID1, TID2, TID3, TID4, etc., may be a unique identifier that identifies a particular transaction. As described above, a transaction can be any time during which a user or user device performs an authentication event. Transactions offered within historical data are whether or not the problem is flagged and / or whether any transfer of money, goods or services is allowed to proceed towards completion. Can be remembered without.

[0151] For example, any kind of identification-related data 503 such as ID1 and ID2 can be stored. The identification-related data may relate to the user who is allegedly conducting the transaction, information about the user's device, or any information specific to the transaction itself. The identification-related data may include authentication data. For example, a username, password or phrase, encryption key, biometric data (eg, fingerprint, eye scan, palm print, voice print) or any other type of information used to authenticate the user may be provided. ..

[0152] The identification data 503 includes a user's name, a unique identifier for the user, or any personal information about the user (eg, the user's address, email, telephone number, birthday, birthplace, website, social security number, etc. It may include account numbers, gender, race, religion, educational information, health-related information, employment information, family information, spouse relationships, dependents or any other information related to the user). Personal information about the user may include financial information about the user. For example, financial information about a user includes user's payment card information (eg, credit card, debit card, gift card, discount card, prepaid card, etc.), user's financial account information, bank branch code, balance, debt amount, credit limit. It may include amounts, past financial transactions or any other type of information.

[0153] The identification data 503 may relate to a physical token. For example, a unique physical token such as a barcode on an ID card may be provided. Identification information encoded in the barcode may be provided.

[0154] The identification data 503 may relate to the user's device. For example, a unique device identifier may be provided. Finger print data of the device (eg, information about one or more characteristics of the device) may be provided. The clock of the device, the IP address of the device, the information collected about the application running on the device or any other information related to the device may be collected.

[0155] Information specific to the transaction may be incorporated. For example, the nature of the transaction, the entity involved in the transaction, the time of the transaction, the amount of exchange of any financial or goods or services relating to the transaction, the account number involved in the transaction or any other information regarding the transaction may be provided.

[0156] In some embodiments, the identification data 503 may be provided by a physical token. The physical token can be the same token as described in FIG. Identification data can be obtained by scanning the physical token using the user device and the scanned image data can be processed to decode the identification data. The identification data to be decrypted may or may not be previously encrypted data. In some embodiments, the identification data stored in the database is an encrypted ciphertext. Optionally, the identification data stored in the database is plaintext data.

[0157] Once the identification data is obtained, the nonce data can be automatically collected. Nonce data can be collected when the image of the physical token is captured. Nonce data can be collected when the image of the physical token is processed or analyzed.

[0158] In some embodiments, nonce data 505 may be collected without the need for additional sensors or additional operations. For example, nonce data regarding the state information of the imaging device can be collected from the captured static token metadata without additional measurement or any manipulation. In another example, nonce data about the state of the imaging data can be collected during image processing without any additional calculation or analysis.

[0159] Nonce data 505 may be collected when an authentication event occurs. The nonce data may include information about the state of the imaging device, the state of the static tokens captured and / or the user device. The nonce data can be data that is extremely unlikely to be repeated within a subsequent authentication event. Nonce data may include or derive data collected from a single point in time or from multiple time points (eg, continuously at various time intervals or within a time range). Nonce data can be stored as a single or multiple sets of data. The nonce data may be shown as ND1, ND2, ND3 and the like.

[0160] Historical data can be analyzed to identify the device and / or the user or to authenticate the user. As shown, the first two transactions may not issue any warnings. For example, regarding TID1 and TID2, since the identification data ID1 and ID2 are related to different transactions, they may be different, and the nonce data ND1 and ND2 may be different because both data sets are different.

[0161] In the third scenario TID3, a warning may be issued. While another transaction is taking place, the same identification data ID1 may indicate that the identification should be the same identification (eg, user) as TID1. The nonce data ND3 may indicate that some information differs between TID1 and TID3 and is therefore unlikely to be the same transaction. This may indicate that the same user makes different transactions. The fact that the identification information ID1 is the same between the TID1 and the TID3 is inconsistent and may increase the possibility of fraud.

[0162] The fourth scenario shows the possibility of issuing a warning. For example, TID4 is shown to be a separate transaction but has the same identification data ID2 and a second transaction TID2. The nonce data ND2 may also be shown to be the same between TID2 and TID4. Nonce data may be very unlikely to be repeated or may never be repeated. Repeated nonce data can indicate a replay attack. Therefore, it is possible to flag the fourth transaction TID4 as having a high probability of a replay attack.

[0163] It is possible that the imager may have a set of operating parameters (eg, the same exposure time) similar to an event, but especially to a high level of accuracy and / or accuracy of the data as described above. If the required measurements are included, the information is perfectly matched (eg, the precision orientation and / or spatial position is exactly the same, or the precision coordinates, orientation, skew angle of the static token with respect to the image frame. Degree, size) is rare. Therefore, in the fourth scenario, there may be some possibility of a replay attack.

[0164] In some scenarios, the nonce data 505 may include nonce information collected at multiple time points during the authentication event. In one example, the nonce information may be collected at any time after the image data is captured, after the static token is decoded, or in between, when the user initiates the imaging device.

[0165] These scenarios are given only as examples. Authentication events can include identifying devices and / or users. For example, identification information may be used to identify a user and / or device. The identification information can be compared with one or more sets of identification information stored in the past. In some embodiments, if the identification information matches a previously stored set of identification information, the identification information may be determined to belong to the same user and / or device.

[0166] Nonce data can optionally be considered when identifying users and / or devices. The nonce data can be analyzed as is and / or compared with one or more sets of nonce data stored in the past. If the nonce data matches exactly the same as the set of nonce data stored in the past, it can be determined that there is a possibility of a replay attack. This may suggest that the user is not the person he claims to be or that the user is providing counterfeit information.

[0167] FIG. 6 shows how the nonce data 601 and the identification data 603 can be used to form the authentication parameter 600 according to an embodiment of the invention. Any description herein of nonce data may apply to the authentication parameters set forth herein. The authentication parameter can be a replay parameter that may include nonce data and identification data. In some embodiments, the identification data can be static data about a user, physical token, device or service. The nonce data can be dynamic data that changes from transaction to transaction. Therefore, the authentication parameters of the present invention may change naturally from transaction to transaction.

[0168] In some embodiments, the authentication parameter 600 may include identification data 603 and nonce data 601 as shown in scenario A. Identification data and nonce data can be collected during the same image capture and analysis process. Identification data and nonce data can be collected using the same static token during a transaction. Identification data and nonce data can be collected by taking a self-portrait image of the user.

[0169] The identification information / data 603 may include any kind of information described elsewhere herein. For example, the identification information can relate to a user, a user device, a physical token held by the user, and / or an authentication event (eg, a transaction). The identification can be a single piece of information (eg, a unique identifier) or can include multifactorial information (eg, any combination of other types of information described elsewhere herein). .. The identification data / information can be a user identification recognized by facial biometrics. For example, by comparing the extracted facial features / marks with the user's face features / marks stored in advance, the user's identification can be obtained when a match is determined.

[0170] In some embodiments, the identification data 603 can be a static token. Static tokens can be provided by physical tokens such as barcodes. The static token can be the same as described in FIG. The identification data can be obtained by capturing the image of the physical token using a user device, processing the image data and decoding the information. In some cases, image processing and decoding may be performed by one or more processors on the board along with the user device. In other cases, image processing and decoding may be performed by one or more processors outside the user device. Captured image data, including physical tokens, can be transmitted to an external device for decoding and / or decoding, and the external device described elsewhere herein is for its own authentication or identification evaluation. Information can be analyzed. In this case, the captured image data may or may not be processed (eg, compressed) before being transmitted to another device.

[0171] The identification data 603 sealed with the nonce data 601 can be data decoded from the physical token. For example, the identification data can be decoded from an image of the graphical code captured by the user device. The captured image may or may not be decoded on the user device. In some cases, the captured image may be decoded on the board of the user device. For example, the user device can be used to scan the PDF417 code on the driver's license and the user identification information can be decrypted by the application or software implemented on the user device.

[0172] The decrypted identification data may or may not be encrypted in the past. The user device may or may not have access to the encryption key or method to decrypt the data. In some embodiments, the decrypted data can be sealed directly with the nonce data as a parameter used for authentication. In some embodiments, if the data has been encrypted in the past, the data can be decrypted by an application or software on the board of the user device and then sealed with the nonce data. In other embodiments, the user device does not have to decrypt the data and therefore may transmit the data for evaluation and analysis to an external device such as an entity involved in a transaction with an encryption key or password. can. The identification data sealed with the nonce data can be of any format and any data type, such as image data, binary, alphanumericals, ASCII, etc.

[0173] In some embodiments, the identification data may or may not be provided by the same image data used to collect the nonce data. For example, the nonce data can be collected from the state of the image pickup device when the image pickup device is capturing the image data, and the same image data may not provide the identification information. In another example, nonce data may be collected from the state of captured image data, including static tokens such as graphical code, which may or may not provide identification information. In a different example, nonce data may be collected from the state of captured image data, including static tokens, which may provide at least a portion of the identification information.

[0174] The nonce data 601 is any kind of nonce data, such as nonce data derived from one or more nonce factors or nonce data which may contain one or more nonce factors in an individually accessible format. possible. The nonce data may or may not be itself sealed. For example, nonce data may or may not be decomposed into its original nonce factor, divided, or derivable. The sealed nonce data may not allow access to the original nonce factor and / or raw data used to derive the nonce data. The unsealed nonce data can allow access to the original nonce factor and / or unprocessed data used to derive the nonce data.

[0175] The nonce data 601 and the identification information 603 can be associated with each other. Nonce data and identification information may be linked or combined with each other. Nonce data and identification information can be used to derive authentication parameters. If the nonce data is the same between authentication events, the authentication parameters can be the same between the authentication events. In some examples, authentication parameters can be the same between authentication events if the nonce data is the same and the identification information is the same. If the nonce data is the same and the identification information is not the same, the authentication parameters may optionally not be the same.

[0176] The nonce data 601 can be linked to an authentication event in which a person who is supposed to be a user participates in the authentication event. Since the nonce data is likely to be different for different authentication events, it may not issue any warning if the nonce data is different for subsequent authentication events and the identification information for this authentication event is different. It can raise questions if the nonce data is different but the identification information is the same. For example, if the same information points to the same authentication event, the nonce data should be the same and should not be different. In another example, if the nonce data is the same and the identification information is different, it may raise the possibility of warning and replay attacks. For example, if different authentication events occur, it is extremely unlikely that the nonce data will match. Nonce data is selected to include data that should change between authentication events. In another example, if the nonce data and identification information are the same, it can happen if the data is recorded multiple times for the same authentication event. Alternatively, any indication of the same nonce data may be a warning, even if the identification information is the same, or may provide some possibility of a replay attack.

[0177] In some embodiments, the shield authentication parameter 600 may include nonce data and identification information in an individually distinguishable or readable format. For example, nonce data can be accessed and read, and identification information can be accessed and read. Shielded authentication parameters can permanently link nonce data and identification information in an inseparable form. In an alternative embodiment, the authentication parameters may not allow the nonce data and identification information to be individually distinguished or readable.

[0178] In some embodiments, the nonce data 601 and the identification data 603 may be encrypted as the shield authentication parameter 600. Nonce data and identification data can be used as input parameters for secret cryptographic algorithms implemented to create authentication parameters. Various methods can be used to encrypt the parameters. For example, symmetric keys can be used for encryption and decryption. These keys can consist of a statement or a set of meaningless strings, and encryption is the data chunks (eg, original data, structural data and read data) that make up the parameters (eg, nonce data and identification data). It is performed by executing a bit-exclusive logical sum operation on (Solomon data). In another example, nonce data and identification data can be encrypted using 1024-bit polymorphic encryption or, depending on export control, the AES256-bit encryption method. Further, encryption can be performed using a remote key (seed) or a local key (seed). As will be appreciated by those of skill in the art, alternative encryption methods such as SHA256, AES, Blowfish, RSA and the like may be used. In some cases, software and / applications on user devices and other authentication systems or entities involved in the transaction may retain cryptographic keys and cryptographic methods.

[0179] The combination of identification data and nonce data (shield authentication parameter) can be used for authentication. Identification data can be provided by static tokens. The identification data can be used to identify the user and / or the device. You can collect nonce data from the process of capturing and analyzing the same static tokens. Nonce data can be used to detect fraud. The nonce data can be analyzed as is and / or compared with one or more sets of nonce data stored in the past. If the nonce data matches exactly the same as the set of nonce data stored in the past, it can be determined that there is a possibility of a replay attack. This may suggest that the user is not the person he claims to be or that the user is providing counterfeit information.

[0180] In some embodiments, the authentication parameter 611 may include additional information, as shown in scenario B of FIG. Additional transaction information may be provided by various sources or means other than the image data used to collect nonce data and identification data. For example, during a transaction, a user may be prompted to scan a graphical code on a card or external device (eg, a barcode on an ID card) for authentication. In addition to the identification information 613 and nonce data 611 collected from the captured image, the user can also enter other transaction information such as user account name, password, financial transaction value. Additional information can be sealed with identification and nonce data and transmitted to other entities involved in the transaction.

[0181] In another embodiment, the additional information may include data according to the dynamic token 615. Dynamic tokens and result data can be used to authenticate user devices or transactions, adding additional security to the authentication process. The dynamic token is provided by the authentication system or entity involved in the transaction and can be received by the user device. Various dynamic tokens can be generated for various transactions. Dynamic tokens can be initially generated by the authentication system and transmitted to the user device. A user can be authenticated if the returned dynamic token or information uniquely associated with the dynamic token matches the first dynamic token.

[0182] In some embodiments, the dynamic token can be an instruction that includes a set of operating parameters for the imaging device. During the transaction, the operating parameters may set some parameters of the imaging device to fixed values. For example, when a camera is used to capture image data of a graphical token, the focal length, ISO speed, flash usage, etc. can be set to constants. In some cases, the user may have to deal with the imaging device settings by adjusting the distance between the physical token and the imager, for example to focus the camera lens on the physical token. ..

[0183] Additional data 615 in response to the dynamic token may be included within the shield authentication parameter. For example, focal lengths, ISO speeds, aperture times, shutter speeds, etc. that can be affected by dynamic tokens can be collected and returned to the authentication system or entity for verification or authentication.

[0184] Instead, the nonce data can be analyzed as a result of receiving a dynamic token. Dynamic tokens can result in changes in nonce data. As described above, the nonce data may include operating parameters of the imaging device. Therefore, evaluating the corresponding data contained within the nonce data can verify the validity of the shielded authentication parameters.

[0185] FIG. 7 shows an example of using identification data and nonce data to identify a user and / or device according to an embodiment of the invention. A set of nonce data and identification data can be collected using the user device 702. The nonce data and the identification data can be stored together with the historical nonce data and the identification data 704. The nonce data and identification data can be compared with one or more sets of nonce data and identification data collected in the past, respectively. 706. 708 can evaluate user identification based on comparison. In some embodiments, transactions may or may not be permitted based on this comparison. Optionally, instructions can be given regarding the likelihood of fraud such as replay attacks.

[0186] A set of nonce data and identification data can be collected during an authentication event 702. The identification data may be provided by physical tokens such as the visual graphical code described elsewhere herein. Image data about the physical token can be captured by the user device. One or more processors may be configured to decode the captured visual graphical code and obtain identification data. In some embodiments, the decrypted identification data may have been previously encrypted by a third party, so that the decrypted identification data may or may not be readable without an encryption key. .. The identification data can be of any format and data type as described above. The identification data can relate to visual graphical code. The identification data can be relevant to the user. The identification data can be related to the service.

[0187] As described elsewhere herein, the identification data may include information related to the same physical token, the same user, the same service, or the same transaction used in a transaction event or the like. The identification data may include information used to authenticate or verify the user's identification. The identification data may include personal information such as a name, birthday, address, nationality, etc. representing the user's identification. The identification data may include product information such as instructions for identifying the product or service, purchase options, service provider information, and the like. The identification data may include any kind of information that can uniquely identify a user, service, transaction, etc.

[0188] The identification data may or may not be provided by the same image data used to collect the nonce data. For example, the nonce data can be collected from the state of the image pickup device when the image pickup device is capturing the image data, and the same image data may not provide the identification information. In another example, nonce data may be collected from the state of captured image data, including static tokens such as graphical code, which may or may not provide identification information. In a different example, nonce data may be collected from the state of captured image data, including static tokens, which may provide some of the identification information.

[0189] Nonce data may be collected at the same time as the identification data is collected. As described elsewhere herein, nonce data can be collected when a physical token containing identification data is scanned by an imaging device, processed by one or more processors, and analyzed. Nonce data can be collected in response to the detection of an authentication event. Nonce data can be collected in response to static tokens (eg, visual graphical code) and captured by the user device using an imaging device. Nonce data can be collected using one or more processors on the user device. Nonce data can be collected using one or more sensors on the user device. Nonce data can be generated based on sensor data collected by one or more sensors on the user device. The nonce data may include or derive data about the condition of the imaging device. The nonce data may include or be derived from such data regarding the state of the captured image data. The nonce data may include or derive data about the state of the user device. The nonce data may include or derive data about the local or environmental conditions of the imaging device. The nonce data may include operating parameters of the imaging device, characteristics of the image data, location information, time-based information or any other type of information described elsewhere herein. Nonce data may include or derive data that is unlikely to be repeated between authentication events. Nonce data is less than 2%, 1%, 0.5%, 0.1%, 0.05%, 0.01%, 0.005% or 0.001% likely to be repeated between authentication events. May contain data. The nonce data may represent singularity values that should not be repeated. In some embodiments, if the nonce data are 100% identical, such a match is very likely to indicate a replay attack or be a replay attack.

[0190] The nonce data may reflect the state of the imaging device and / or the state of the captured image data at a single point in time or over multiple time points. The nonce data can be substantially unique for that authentication event. The collected data from the user device may be optionally communicated to a device outside the user device. The collected data can be interpreted on the board of the user device to generate a set of nonce data. Alternatively, a device external to the user device may generate nonce data based on the collected data received. If the external device produces nonce data, the nonce data may or may not be sent back to the user device.

[0191] Once a set of nonce data is generated, the nonce data can be sealed with identification data for authentication 704. The shielded authentication parameter, including the identification data and the nonce data, can be the same authentication parameter 600 as set forth in FIG. Shielded authentication parameters may or may not be further encrypted to provide additional security to the transaction event. In some embodiments, sealed identification data and nonce data can be transmitted to a trading entity such as a server or other type of host device that requires user authentication. The trading entity may or may not need to decrypt the shield authentication parameters in order to obtain the nonce data and identification data.

[0192] When a set of nonce data is generated, the nonce data can be stored together with the identification data as historical nonce data and historical identification data 706. The method of storing the nonce data and the identification data may be the same as described in FIG. Historical nonce data and identification data may be stored in one or more memory units. Historical nonce data and identification data can be stored in memory on the board of the user device and on the board of a device external to the user device (eg, a host server of any of the above types, a separate device). It can be stored in memory or distributed across multiple devices (eg, peer-to-peer, cloud computing-based infrastructure between user devices and external devices). In some embodiments, nonce data can be generated on the board of the user device and stored on the board of the user device, external device, or distributed across multiple devices. In other embodiments, the nonce data can be generated on the board of the external device, stored on the board of the external device or user device, or distributed across multiple devices. One or more memory units may include a database. A single copy of historical nonce data and identification data can be stored, or multiple copies can be stored. Multiple replicas may be stored in different memory units. For example, multiple copies can be stored on different devices (eg, the first copy on the board of the user device and the second copy on the board of the external device).

[0193] Historical nonce data may include data collected using one or more sensors and one or more processors on the user device. Historical nonce data may include nonce data that belongs to the same user, the same physical token, and / or is associated with the same device. For example, if the current set of nonce data is collected for a first user, the historical position data may include nonce data collected for the same user. Historical nonce data may include all nonce data for the same user (and / or device) collected using the same device. The historical nonce data may or may not include "registered" nonce data. In some embodiments, the user can register the user's identification and / or the user's device identification by performing initial authentication. The set of nonce information generated by the initial authentication can be stored as registered nonce data. Instead, registration nonce data is not specifically created. Various nonce data from all authentication events for the user (and / or the same device) may be stored. Instead, only registered nonce data may be stored. Instead, only the most recent set of nonce data for a particular user (and / or user device) may be stored. In some examples, only the most recent set of nonce data for a particular user (and / or device) may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, ... 5, 6, 7, 8, 9, 10 or more.

[0194] In some embodiments, the historical nonce data may include nonce data collected by a user device belonging to any user who has interacted with the user device. For example, multiple users may have used a user device to conduct a transaction or authentication event. Historical nonce data may include nonce data belonging to various users (and / or devices of the same user or different users), which may include those who are alleged to be the same user. For example, if the current set of nonce data is collected for the first device, the historical nonce data may include a set of nonce data collected for the same user and other users. Historical nonce data may include all nonce data for one or more users collected using the same device. The historical nonce data may or may not include "registered" nonce data. In some embodiments, the user can register the user or the user's device by performing an initial authentication event. The set of nonce data generated by the initial authentication event may be stored as registered nonce data for that user or for that user's equipment. Such registration may be done for multiple devices and / or multiple users. In some examples, each device may need to be registered the first time it is used for an authentication event. Instead, registration nonce data is not specifically created. Various sets of nonce data from all authentication events can be stored. Instead, only registered nonce data may be stored per device or user. Instead, only the most recent set of nonce data for each device or user may be stored. In some examples, only the most recent X sets of nonce data for each device or user may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6, 7. , 8, 9, 10 or more.

[0195] As described above, historical data may relate to data collected using a particular user device. Alternatively, data from the user device may be shared and / or aggregated. Historical data may include data from multiple user devices. Historical data may include nonce data collected by multiple user devices. Such collection may include the same user or multiple users performing authentication events on a single user device or across multiple user devices. Historical data may include data about a user device that may be providing information to a database of historical nonce data or all users who may be interacting with multiple user devices. For example, an external device, such as a server or any other device described elsewhere herein, may receive nonce data from one or more user devices and store historical nonce data.

[0196] After collecting a set of nonce data and identification, the nonce data and identification can be compared with one or more sets of previously collected nonce data and identification data 708. Such comparison may include comparing the identification data with the historical identification data for authentication or identification, and then comparing the set of nonce data with the historical nonce data associated with the identification to detect fraud. A set of nonce data can be compared to a set of nonce data that is said to be derived from the same identification data (eg, the same user's physical token used for the authentication event, the same user or the same user device, etc.). For example, the identification data may contain identification information such as a user's name or other identifier, or may be used to access an account to which the user's name or other identifier may be accessed. The identification information can be used to identify who is considered to be the same user. For example, if the identification information indicates that the user is John Doe, then one set of nonce data can be compared to another set of nonce data belonging to John Doe. This nonce data may only be compared to the nonce data for all John Doe cards or the same John Doe physical tokens used in the authentication event. If the collected nonce data matches exactly the same as the nonce data stored in the past, there is some indication that the user may be the same user previously identified as John Doe. Suspicion can arise. The natural occurrence of an exact match is very unlikely and may indicate a replay attack.

[0197] A set of nonce data may be compared to any or all of previously collected sets of nonce data that appear to belong to the same user. This comparison can be narrowed down more clearly to the same physical token of the user, or can be applied to any or all physical tokens of the same user. For example, if a set of registered nonce data is provided, the set of collected nonce data can be compared to the set of registered nonce data. The collected nonce data can be compared with the registered nonce data without being compared with any other nonce data, can be compared with the registered nonce data and other nonce data, or is compared with the registered nonce data. It can be compared with other nonce data without any notice. In some examples, the nonce data may be compared to the most recently collected nonce data. The nonce data is a predetermined number of nonce data collected most recently, for example, two sets of the most recently collected nonce data, three sets of the most recently collected nonce data, four sets of the most recently collected nonce data, and the latest. It can be compared with the 5 sets of nonce data collected in, and any number of the most recently collected nonce data can be compared as well.

[0198] In some embodiments, the nonce data can be inspected to determine if the nonce data is within a predetermined range. If it is detected that the nonce data is out of range, the data is likely to have been maliciously modified by a fraudster. For example, the nonce data derived from the orientation angle of the barcode area with respect to the image frame can be in the range 0000-3600 (in 4-number format), and it is detected that this number is out of range, such as 3800. If so, it may indicate fraud.

[0199] The nonce data can be compared with the nonce data that is said to be derived from any user whose identification information is stored in the historical nonce data. If a set of nonce data is collected, identification information that may contain data about the user and / or the user device may be collected during the authentication event. As discussed earlier, the identification information can be used to identify the user. The identification information can be used to identify who is considered to be the same user. For example, if the identification information indicates that the user is John Doe, or if the identification information is used to find out that the user is John Doe, the card nonce data stores John Doe and historical data. Can be compared to other nonce data belonging to any other user that may be. If the collected nonce data matches exactly the same as the nonce data stored in the past, such a match can raise suspicion of a replay attack.

The set of nonce data may be compared to any or all of the previously collected sets of nonce data alleged to belong to any of the users who participated in the authentication event. For example, if the nonce data is provided for various users, the nonce data may be compared with the registered nonce data of the various users. The nonce data can be compared with the registered nonce data without being compared with any other nonce data, can be compared with the registered nonce data and other nonce data, or without being compared with the registered nonce data. Can be compared with other nonce data. In some examples, the nonce data may be compared to the most recently collected nonce data for each of the user or the user's equipment. The nonce data is a predetermined number of nonce data collected most recently, for example, two sets of the most recently collected nonce data, three sets of the most recently collected nonce data, four sets of the most recently collected nonce data, and the latest. It can be compared with the 5 sets of nonce data collected in, and any number of the most recently collected nonce data can be compared as well.

[0201] User identification based on comparison can be evaluated 710. Identification may include authenticating that the user is a real user based on the identification data. For the same identification data, if the collected set of nonce data issues a warning when compared to a previously stored set of nonce data (eg, the match is too complete), then the current authentication event is the same so far. There may be instructions that the user has not done so. For example, if the nonce data is an exact match and there is a set of past nonce data about John Doe, the current user attempting to authenticate may not be John Doe. The same identification and / or authentication can be performed on the user device. For example, a warning may be issued if the user device identifies itself as a particular device and the same nonce data is collected for past authentication events. There may be instructions that the current authentication event is not being performed by the same device and another device may be participating in the replay attack.

[0202] Optional instructions can be given regarding the possibility of fraud. For example, if the identification data identifies as a particular user (eg John Doe) and the nonce data matches exactly the same as the nonce data from a previous authentication event for the same user (eg John Doe), it is fraudulent. It can provide possibilities. Possibility of fraud can be a binary indicator (eg, fraud alert, no fraud) or can be provided as a risk value (eg, a numerical value such as a percentage or a grade value such as a written grade). For example, a fraud grade of 9 may give a higher chance of fraud than a fraud grade of 2.

[0203] The collected nonce data can be exactly the same as the previously stored set of nonce data in order to be considered an exact match (eg, 100% match). A perfect 100% match can be suspicious. For example, there is likely to be some slight variation each time the user performs an authentication event. It is extremely unlikely that an individual will perform an authentication event in exactly the same position (eg, orientation and / or spatial position). In another example, it is extremely unlikely that you will capture the exact same image of a physical token. Having exactly the same characteristics can be a kind of indicator of a replay attack.

[0204] In some embodiments, one or more individuals may be alerted when the risk of fraud is detected. For example, a user performing an authentication event may or may not be notified that his or her attempt at authentication has been flagged at some risk of fraud. The entity with which the user is trying to make a transaction may or may not be informed of the risk of fraud. For example, if a user is trying to purchase an item from an e-commerce site, the e-commerce site may be informed that the transaction has been flagged at some risk of fraud. The transaction itself may or may not be allowed to continue. In some cases, trading can be suspended at any risk of fraud. Instead, if there is some risk of fraud, but it is determined to be low, one or more parties may be notified of some risk of fraud while the transaction may continue and / or Further inspection may be done. If the risk of fraud exceeds a threshold level (eg, a moderate or high risk of fraud is reached), the transaction can be suspended.

[0205] Any kind of fraud can be detected. In some embodiments, the detected fraud may include a replay attack. Data may be recorded during a replay attack, during an authentication event, and replayed within a subsequent authentication event to impersonate the same user, user device, or to complete an authentication event (eg, complete a transaction). There is. The replay attack can be carried out by a different user than the initial authentication event or by the same user as the initial authentication event. The replay attack can be carried out using the same device as the initial authentication event or using a device different from the initial authentication event.

[0206] In some examples, the threshold for stopping a transaction may depend on the value of the transaction or other characteristics of the transaction. For example, in high-priced transactions, the threshold for stopping the transaction may be lower than in low-priced transactions. For example, when a transaction involves a large amount of money, even a low risk of fraud may suspend the transaction, while a small amount may require a higher risk of fraud to suspend the transaction. Instead, the threshold for stopping a transaction can be the same for all transactions.

[0207] Sealed nonce data and identification data may be collected during and / or in response to an authentication event. For example, nonce data and identification data may be collected when the user is trying to self-identify and / or authenticate himself. The user may attempt to self-identify and / or be authenticated in order to access and / or conduct transactions with the user account. The sealed nonce data and identification data can be used individually or in combination for authentication of the device and / or user. The sealed nonce data and identification data may be used individually or in combination with other information such as financial information when approving a transaction. The sealed nonce data and identification data can be used alone to detect fraud.

[0208] In some embodiments, when the nonce data and identification data are analyzed, data on all may be collected from a single event. All nonce data and identification data can be evaluated at the same time. In some other embodiments, the nonce data, identification data can be evaluated sequentially or in various orders.

[0209] Various steps of the authentication process can be performed on the user device. As described elsewhere herein, the user device can be, for example, one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. For example, the user device can be a computing device capable of executing software or applications. In some embodiments, the software and / or application collects identification and nonce data by allowing the user to scan the graphical code / token using the user device, 702, processing the captured image. It may be configured to collect identification and nonce data by decoding identification information, collecting nonce data, and transmitting shielded authentication data between the user device and other external device or system during the transaction. .. The software and / or application may or may not encrypt the shielded authentication data. In some embodiments, the software and / or application is configured to indicate to the user the type of physical token to be captured, based on instructions received from other devices or entities involved in the transaction or predetermined instructions. be able to.

[0210] In some embodiments, the software and / or application compares the identification and nonce data with historical data on the user device 708 and then evaluates for further identification or authentication 710 during the transaction. It may be configured to provide to another device or system. In other embodiments, the software and / or application may be configured to perform comparison 708 and identification / authentication 710 on the user device to complete the transaction.

[0211] The software and / or application may or may not be configured to seal identification and nonce data with additional transaction information. In some embodiments, additional transaction information may be provided by various sources or means other than the image data used to collect nonce data. For example, during a transaction, a user may be prompted to scan a graphical code on a card or external device (eg, a barcode on an ID card) for authentication. In addition to the identification and nonce data collected from the captured images, the user can also enter other transaction information such as user account names, passwords, financial transaction values and the like. Additional information can be sealed with identification and nonce data and transmitted to other entities involved in the transaction.

[0212] Software and / or applications may be further configured to control the imaging device. In some embodiments, a dynamic token containing a set of operating parameters for the imaging device may be received by the software and / or application. The dynamic token can be the same dynamic token as described in FIG. Therefore, the software can instruct the image pickup device to capture image data using parameters based on dynamic tokens.

[0213] In other embodiments, nonce data can be used only for fraud detection. The nonce data can be analyzed as is and / or compared with one or more sets of nonce data stored in the past. If the nonce data matches exactly the same as the set of nonce data stored in the past, it can be determined that there is a possibility of a replay attack. This may suggest that the user is not the person he claims to be or that the user is providing counterfeit information.

[0214] FIG. 8 shows an example of using nonce data to identify a user and / or device according to an embodiment of the invention. A set of nonce data can be collected using the user device 802. The nonce data can be stored together with the historical nonce data 804. The nonce data can be compared with one or more sets of nonce data collected in the past 806. 808 can evaluate user identification based on comparison. In some embodiments, transactions may or may not be permitted based on this comparison. Optionally, instructions can be given regarding the likelihood of fraud such as replay attacks. Any description of the shielded certification data elsewhere herein may apply to the nonce data presented herein.

[0215] A set of nonce data can be collected during an authentication event 802. Nonce data can be collected continuously or in response to a schedule. Nonce data can be collected in response to the detection of an authentication event. Nonce data can be collected in response to image-based tokens and captured by the user device. Nonce data can be collected using one or more processors on the user device. Nonce data can be collected using one or more sensors on the user device. Nonce data can be generated based on sensor data collected by one or more sensors on the user device. The nonce data may include or derive data about the condition of the imaging device. The nonce data may include or be derived from such data regarding the state of the captured image data. The nonce data may include or derive data about the state of the user device. The nonce data may include or derive data about the local or environmental conditions of the imaging device. The nonce data may include operating parameters of the imaging device, characteristics of the image data, location information, time-based information or any other type of information described elsewhere herein. Nonce data may include or derive data that is unlikely to be repeated between authentication events. Nonce data is less than 2%, 1%, 0.5%, 0.1%, 0.05%, 0.01%, 0.005% or 0.001% likely to be repeated between authentication events. May contain data. The nonce data may represent singularity values that should not be repeated. In some embodiments, if the nonce data are 100% identical, such a match is very likely to indicate a replay attack or be a replay attack.

[0216] The nonce data may reflect the state of the imaging device and / or the state of the captured image data at a single point in time or over multiple time points. The nonce data can be substantially unique for that authentication event. The collected data from the user device may be optionally communicated to a device outside the user device. The collected data can be interpreted on the board of the user device to generate a set of nonce data. Alternatively, a device external to the user device may generate nonce data based on the collected data received. If the external device produces nonce data, the nonce data may or may not be sent back to the user device.

[0217] When a set of nonce data is generated, the nonce data may be stored together with the historical nonce data 804. Historical nonce data may be stored in one or more memory units. Historical nonce data can be stored in memory on the board of the user device and in memory on the board of a device external to the user device (eg, a separate device of any of the above types). Can be or can be distributed across multiple devices (eg, peer-to-peer, cloud computing-based infrastructure between user devices and external devices). In some embodiments, nonce data can be generated on the board of the user device and stored on the board of the user device, external device, or distributed across multiple devices. In other embodiments, the nonce data can be generated on the board of the external device, stored on the board of the external device or user device, or distributed across multiple devices. One or more memory units may include a database. A single copy of historical nonce data can be stored, or multiple copies can be stored. Multiple replicas may be stored in different memory units. For example, multiple copies can be stored on different devices (eg, the first copy on the board of the user device and the second copy on the board of the external device).

[0218] Historical nonce data may include data collected using one or more sensors and one or more processors on the user device. Historical nonce data may include nonce data that belongs to the same user and / or is associated with the same device. For example, if the current set of nonce data is collected for a first user, the historical position data may include nonce data collected for the same user. Historical nonce data may include all nonce data for the same user (and / or device) collected using the same device. The historical nonce data may or may not include "registered" nonce data. In some embodiments, the user can register the user's identification and / or the user's device identification by performing initial authentication. The set of nonce information generated by the initial authentication can be stored as registered nonce data. Instead, registration nonce data is not specifically created. Various nonce data from all authentication events for the user (and / or the same device) may be stored. Instead, only registered nonce data may be stored. Instead, only the most recent set of nonce data for a particular user (and / or user device) may be stored. In some examples, only the most recent set of nonce data for a particular user (and / or device) may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, ... 5, 6, 7, 8, 9, 10 or more.

[0219] In some embodiments, the historical nonce data may include nonce data collected by a user device belonging to any user who has interacted with the user device. Historical nonce data may include nonce data belonging to various users (and / or devices of the same user or different users), which may include those who are alleged to be the same user. Historical nonce data may include all nonce data for one or more users collected using the same device. The historical nonce data may or may not include "registered" nonce data. In some embodiments, the user can register the user or the user's device by performing an initial authentication event. The set of nonce data generated by the initial authentication event may be stored as registered nonce data for that user or for that user's equipment. Such registration may be done for multiple devices and / or multiple users. In some examples, each device may need to be registered the first time it is used for an authentication event. Instead, registration nonce data is not specifically created. Various sets of nonce data from all authentication events can be stored. Instead, only registered nonce data may be stored per device or user. Instead, only the most recent set of nonce data for each device or user may be stored. In some examples, only the most recent X sets of nonce data for each device or user may be stored, where X is a predetermined number, eg, X = 1, 2, 3, 4, 5, 6, 7. , 8, 9, 10 or more.

[0220] After collecting a set of nonce data, the nonce data can be compared with one or more sets of previously collected nonce data 806. Such comparison may include comparing a set of nonce data with historical nonce data. A set of nonce data can be compared to a set of nonce data allegedly derived from the same user (or the same user device). For example, if a set of nonce data is collected, additional information that may include authentication / identification information may be collected during the authentication event. This additional information may include identifying information such as the user's name or other identifier, or may be used to access an account to which the user's name or other identifier may be accessed. Additional information can be used to identify alleged same users. For example, if additional information indicates that the user is John Doe, then one set of nonce data can be compared to another set of nonce data belonging to John Doe. This nonce data may be compared to nonce data for all John Doe cards or only for the same John Doe user device as used for the authentication event. If the collected nonce data matches exactly the same as the previously stored nonce data, there is some possibility that the user may be the same user previously identified as John Doe. Suspicion can arise. The natural occurrence of an exact match is very unlikely and may indicate a replay attack.

[0221] Additional information may include identification data described elsewhere herein. The identification information can be the same identification information as described in FIG.

[0222] A set of nonce data may be compared to any or all of previously collected sets of nonce data that appear to belong to the same user. This comparison can be narrowed down more clearly to the same device of the user, or can be applied to any device or all devices of the same user. For example, if a set of registered nonce data is provided, the set of collected nonce data can be compared to the set of registered nonce data. The collected nonce data can be compared with the registered nonce data without being compared with any other nonce data, can be compared with the registered nonce data and other nonce data, or is compared with the registered nonce data. It can be compared with other nonce data without any notice. In some examples, the nonce data may be compared to the most recently collected nonce data. The nonce data is a predetermined number of nonce data collected most recently, for example, two sets of the most recently collected nonce data, three sets of the most recently collected nonce data, four sets of the most recently collected nonce data, and the latest. It can be compared with the 5 sets of nonce data collected in, and any number of the most recently collected nonce data can be compared as well.

[0223] In some embodiments, the nonce data can be inspected to determine if the nonce data is within a predetermined range. If it is detected that the nonce data is out of range, the data is likely to have been maliciously modified by a fraudster. For example, the nonce data derived from the orientation angle of the barcode area with respect to the image frame can be in the range 0000-3600 (in 4-number format), and it is detected that this number is out of range, such as 3800. If so, it may indicate fraud.

[0224] The nonce data can be compared with the nonce data that is attributed to any user whose information is stored in the historical nonce data. If a set of nonce data is collected, additional information that may contain data about the user and / or the user device may be collected during the authentication event. As discussed above, the additional information may include identifying information that may be used to identify the user. Additional information can be used to identify alleged same users. For example, if additional information indicates that the user is John Doe, or if additional information is used to find out that the user is John Doe, the card nonce data stores John Doe and historical data. Can be compared to other nonce data belonging to any other user that may be. If the collected nonce data matches exactly the same as the nonce data stored in the past, such a match can raise suspicion of a replay attack.

The set of nonce data may be compared to any or all of the previously collected sets of nonce data alleged to belong to any of the users who participated in the authentication event. For example, if the nonce data is provided for various users, the nonce data may be compared with the registered nonce data of the various users. The nonce data can be compared with the registered nonce data without being compared with any other nonce data, can be compared with the registered nonce data and other nonce data, or without being compared with the registered nonce data. Can be compared with other nonce data. In some examples, the nonce data may be compared to the most recently collected nonce data for each of the user or the user's equipment. The nonce data is a predetermined number of nonce data collected most recently, for example, two sets of the most recently collected nonce data, three sets of the most recently collected nonce data, four sets of the most recently collected nonce data, and the latest. It can be compared with the 5 sets of nonce data collected in, and any number of the most recently collected nonce data can be compared as well.

[0226] User identification based on comparison can be evaluated. Identification may include authenticating that the user is a real user based on authentication and / or identification information. For the same additional information, if the collected set of nonce data issues a warning when compared to a previously stored set of nonce data (eg, the match is too complete), then the current authentication event is the same so far. There may be instructions that the user has not done so. For example, if the nonce data is an exact match and there is a set of past nonce data about John Doe, the current user attempting to authenticate may not be John Doe. The same identification and / or authentication can be performed on the user device. For example, a warning may be issued if the user device identifies itself as a particular device and the same nonce data is collected for past authentication events. There may be instructions that the current authentication event is not being performed by the same device and another device may be participating in the replay attack.

[0227] Optional instructions can be given regarding the possibility of fraud. For example, various authentication and / or identification information identifies as a particular user (eg John Doe), and the nonce data is exactly the same as the nonce data from a previous authentication event of the same user (eg John Doe). If it matches, it can provide the possibility of fraud. Possibility of fraud can be a binary indicator (eg, fraud alert, no fraud) or can be provided as a risk value (eg, a numerical value such as a percentage or a grade value such as a written grade). For example, a fraud grade of 9 may give a higher chance of fraud than a fraud grade of 2.

[0228] The collected nonce data can be exactly the same as the previously stored set of nonce data in order to be considered an exact match (eg, 100% match). A perfect 100% match can be suspicious. For example, there is likely to be some slight variation each time the user performs an authentication event. It is extremely unlikely that an individual will capture the exact same image data of a physical token to perform an authentication event. Having exactly the same characteristics can be a kind of indicator of a replay attack.

[0229] In some embodiments, one or more individuals may be alerted when the risk of fraud is detected. For example, a user performing an authentication event may or may not be notified that his or her attempt at authentication has been flagged at some risk of fraud. The entity with which the user is trying to make a transaction may or may not be informed of the risk of fraud. For example, if a user is trying to purchase an item from an e-commerce site, the e-commerce site may be informed that the transaction has been flagged at some risk of fraud. The transaction itself may or may not be allowed to continue. In some cases, trading can be suspended at any risk of fraud. Instead, if there is some risk of fraud, but it is determined to be low, one or more parties may be notified of some risk of fraud while the transaction may continue and / or Further inspection may be done. If the risk of fraud exceeds a threshold level (eg, a moderate or high risk of fraud is reached), the transaction can be suspended.

[0230] Any kind of fraud can be detected. In some embodiments, the detected fraud may include a replay attack. Data may be recorded during a replay attack, during an authentication event, and replayed within a subsequent authentication event to impersonate the same user, user device, or to complete an authentication event (eg, complete a transaction). There is. The replay attack can be carried out by a different user than the initial authentication event or by the same user as the initial authentication event. The replay attack can be carried out using the same device as the initial authentication event or using a device different from the initial authentication event.

[0231] In some examples, the threshold for stopping a transaction may depend on the value of the transaction or other characteristics of the transaction. For example, in high-priced transactions, the threshold for stopping the transaction may be lower than in low-priced transactions. For example, if the transaction is for a large amount, even a low risk of fraud may suspend the transaction, while for a small amount, a higher risk of fraud may be required to suspend the transaction. Instead, the threshold for stopping a transaction can be the same for all transactions.

[0232] Nonce data may be collected during and / or in response to an authentication event. For example, nonce data can be collected when a user is trying to self-identify and / or authenticate himself. The user may attempt to self-identify and / or be authenticated in order to access and / or conduct transactions with the user account. Nonce data can be used individually or in combination with other information for identification. The nonce data can be used individually or in combination when authenticating the device and / or the user. Nonce data may be used individually or in combination with other information such as financial information when approving a transaction. Nonce data can be used alone or in combination with other information for fraud detection.

[0233] In some embodiments, when nonce data and / or any other information is analyzed, data on all may be collected from a single event. All of the nonce data and / or any other information can be evaluated at the same time. In some other embodiments, nonce data and / or other information may be evaluated sequentially or in various orders.

[0234] In some embodiments, authentication parameter data may be used when identifying and / or authenticating a user. It can be used within the trading process. Authentication parameters may or may not be used to assess the likelihood of fraud. The authentication parameter data can optionally be used within a process similar to FIG. 7, in which the authentication parameters can be stored and compared in a history database. The authentication parameter data described above may include nonce data and identification data. In some embodiments, the identification data can be static tokens.

[0235] FIG. 9 provides an example of an entity involved in an authentication event according to an embodiment of the invention. As described above, any kind of authentication event that may take place as described elsewhere herein, such as various transactions, may be used. Authentication can be performed on various transactions that may or may not include the exchange of money and / or goods or services. Transactions may or may not include the exchange of information. Authentication can include any situation in which the user can verify the identity of the user or user device.

[0236] The authentication system may include one or more user devices 900a, 900b, 900c, 900d capable of communicating with one or more external devices 910, 920. One or more user devices may be associated with one or more individual users. Communication may occur on network 930 or directly. Physical tokens such as graphical codes 960a, 960b, 970d can be captured and analyzed by one or more user devices and data (eg, identification data and nonce data) can be collected. The self-portrait image of the user 970c can be captured by one or more user devices and data (eg, user identification and nonce data) can be collected. In some cases, in addition to capturing the image of the physical token 960b, the user 970e's selfie image and associated nonce data can be used. Data 940a, 940b, 940c, 940d from one or more user devices can be transmitted to one or more external devices. In some embodiments, the data 950a received by the first external device can be the same as the data 950b received by the second external device, or the data can be different. In one example, the first external device may be an authentication server system (eg, a server system configured to perform secure authentication) or may belong to an authentication server system, and / or the second external device may be. It can be one or more third parties (eg, any trading entity described elsewhere herein, such as a retailer's system, an intermediary's system, another entity that requires authentication of identification, etc.). Or it may belong to such a third party.

[0237] The network 930 can be a communication network. The communication network may include a local area network (LAN) or a wide area network (WAN) such as the Internet. A communication network may include a telecommunications network that includes a transmitter, a receiver, and various communication channels (eg, routers) for routing messages between them. Communication networks include Ethernet, Universal Serial Bus (USB), FIREWIRE, Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Time Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, It can be implemented using any known network protocol, including various wired or wireless protocols, such as Wi-Fi, Voice Over Internet Protocol (VoIP), Wi-MAX, and any other suitable communication protocol. ..

[0238] User devices 900a, 900b, 900c, 900d may include one or more characteristics of various embodiments of the user device described elsewhere herein. For example, a user device may have one or more characteristics, components or functions of the user device of FIG. The user device may include an imaging device configured to capture static tokens. In some embodiments, the user device may include one or more processors configured to handle various requests from the user, the first external device 910 and / or the second external device 920. The user device may have transaction information, transaction data, authentication information, identification information, financial information, user account information related to the user device, device information of the user device, and interaction with the user device, without limitation. One or more for storing various information including device identifiers of card readers, nonce data, history authentication data and / or usage data related to the user of the user device (eg, other activity data related to the user). It can also contain or access such a database. Different types of user devices may be used to assist in authentication. The authentication system may include multiple types of user devices that can be used simultaneously.

[0239] Different types of user devices are, but are not limited to, handheld devices, wearable devices, mobile devices, tablet devices, laptop devices, desktop devices, computing devices, telecommunications devices, media players, navigation devices, games. It may include a machine, a television, a remote control, a combination of any two or more of these data processing devices, or other data processing devices. Optionally, the user device may be able to read a magnetic card, such as any type of payment card. The user device may be able to perform authentication reading of the payment card. The user device may accept a payment card swipe and may be able to read magnetic information from the payment card. The device used may be able to read one or more of the payment card's swipe characteristics, such as the speed, direction, angle, variation and / or inherent magnetic properties of the payment card's swipe. Alternatively, the user device may connect to a card reader having any of the features described herein.

[0240] The first external device 910 may include one or more processors. The first external device can be an authentication server system. The first external device may include or access one or more databases. The first external device may communicate with one or more user devices 900a, 900b, 900c, 900d. The first external device may communicate with various user devices using a communication unit (eg, an I / O interface). The first external device may communicate with a system of various trading entities (eg, retailer's system, intermediary's system, credit card company, social network platform and / or other entity). The first external device may communicate with various external server systems using one or more I / O interfaces. The I / O interface to the user device and / or the card reader may assist in processing the inputs and outputs associated with each of the user device and / or the card reader. For example, the I / O interface may assist in processing user input associated with a request for secure authentication. The I / O interface to the external server system communicates with one or more third party entities (eg, retailer's system, intermediary's system, credit card company, social network platform and / or other entity). Can assist.

[0241] The first external device may include a memory storage unit that may include a non-transitory computer-readable medium containing code, logic or instructions for performing one or more steps. One or more processors of the first external device may be able to perform one or more steps according to, for example, a non-transitory computer-readable medium. In some embodiments, one or more processors perform secure authentication, process the request, compare nonce data and identification data, identify the information required for authentication, authenticate, and respond to the request. And can generate or receive a request to return the authentication result. One or more databases are, but are not limited to, corresponding nonce data, corresponding identification data, account information associated with each user, device information of the user device (eg, user device identifier), history authentication data and /. Alternatively, various information including usage data related to each user (for example, activity data related to each user) may be stored.

[0242] The data stored about the user may include identifying information about the user. The identification information may include name, birth data, address, telephone number, gender, social security number or any other personal information about the user.

[0243] The data stored about the user may include financial information about the user. Financial information may include a card reader for the user and / or account information for the user. The user's card information includes the type of card (eg, credit card, membership card, identification card, etc.), the card issuer (eg, credit carrier, company, government, etc.), and the type of credit carrier (eg, Visa, Mastercard, American). Express, Discover, etc.), card number, card expiration date and / or card security code. Account information relates to the user's name, user's mailing address, user's phone number, user's email address, user's birthday, user's gender, user's social security number, user account ID and associated password or user. It may contain any other personal information.

[0244] Transaction-related data such as nonce data can be stored. The nonce data may be associated with a user or user device for a particular authentication event (eg, a transaction). Nonce data is very unlikely to be derived or repeated individually or in combination (eg, with a probability of 1% or less, 0.5% or less, 0.1% or less, 0.05% or less). , 0.01% or less, 0.005% or less, 0.001% or less, 0.0005% or less, 0.0001% or less, 0.00005% or less, 0.00001% or less, 0.000005% or less or 0 May include information about device conditions or parameters (less than or equal to 0.0001%). The nonce data may represent the singularity value of the device at that particular time point or time interval.

[0245] Shielded authentication parameters, including identification data and nonce data, can be stored in one or more databases as described in FIG.

[0246] Different types of information (eg, financial information, user information, device information and / or nonce data) may be obtained during various authentication activities of the user and stored in the database 950a of the first external device. The first external device may have access to a database or a subset of databases for storing different types of information. The different types of information may also be obtained or not obtained, stored or not stored during the initial registration of the user in the first external device (eg, the authentication server system). In some embodiments, different types of information may be accessible by a first external device. For example, a second external device (eg, a third party entity) 920 may or may not have access to the same database or subset of the same database for storing different types of information.

[0247] The second external device 920 may be a third party entity or may belong to a third party entity. The third party entity may be implemented on a distributed network of one or more stand-alone data processing devices or computers. In some embodiments, the entity uses various virtual devices and / or services of a third-party service provider (eg, a third-party cloud service provider) to provide the underlying computational and / or infrastructure resources. There is also. In some embodiments, the third party trading entity may or may not store card information, account information, usage data, nonce data and / or device information associated with the user at the time of user approval and according to the privacy policy involved. good. One or more third-party trading entities are authenticated by e-commerce systems, retail systems, financial institutions (eg banks, intermediaries and credit card companies), retailer systems, social net working platforms and / or users. It may include other entities of interest. In some examples, the third party entity can be an online e-commerce and can analyze the user's nonce data relating to the user's device to complete or reject the purchase of the product online. In some examples, the third party entity can be an intermediary system and can analyze nonce data to verify the transfer of funds between a user's financial account and the intermediary system. In some examples, the third party entity can be a social networking platform that hosts multiple user accounts. The user may use the nonce data to verify the user's login to the social networking platform.

[0248] As described above, the data 950a accessible by the first external device and the data 950b accessible by the second external device may be the same or different. In some embodiments, the first external device may be an authentication system that may be accessible to a larger amount of data, and / or the second external device may be accessible to a smaller amount of data. Can be a third party entity. Both the first external device and the second external device may have access to nonce data and / or data related to any authentication event (eg, transaction data). Alternatively, the first external device may be able to obtain nonce data, while the second external device may not be able to access the nonce data, and vice versa. Optionally, the data associated with the authentication event or a subset thereof is obtained by both the first external device and / or the second external device or by only one of the first external device or the second external device. obtain.

[0249] External devices 950a and 950b may or may not be entities and provide the user with one or more physical tokens 960a, 960b, 960d. The external device may or may not need to decrypt the identification data in order to verify or authenticate the user. In some embodiments, the external devices 950a and 950b may be entities that provide the graphical code 970d on the display device for the user to scan. The graphical code (eg, QR code) may be under exclusive rights, whereby such graphical code may only be read by an authenticated application provided by an authentication system running on the user device. .. In some examples, only an authentication system or authentication application can encrypt / decrypt the graphical code. The graphical code can encode the identification information that can be used as a static token to authenticate the user. When the code is scanned by the user device 900d, nonce data is automatically generated and can be used to detect fraud.

[0250] As previously described, the data 940a, 940b, 940c, 940d from one or more user devices may be accessible by a first external device and / or a second external device. Data from one or more user devices may include data regarding nonce data and identification data and / or device conditions or parameters that may be used to derive or generate nonce data. For example, for an authentication event, the user device may transmit the corresponding nonce data and / or information related to the authentication event. Data may be transmitted in response to an authentication event. The data can be pushed by the user device or pulled by a first external device or a second external device. Data can be transmitted in real time. Alternatively, the data may be transmitted periodically or in response to a schedule. In some embodiments, the user device can transmit data about the state of the imager or data about the state of the captured image data of the static token, which data is elsewhere (eg, first external). It can be used to generate nonce data (in the device and / or a second external device). The data relating to the state of the image pickup apparatus and the captured image data are as described elsewhere in this specification. The data regarding the state of the image pickup device and the captured image data may include data collected using one or more processors outside the board of the device. In some embodiments, data about the state of the imaging device and image data may include unprocessed or preprocessed data from one or more sensors and processors on or off the board of the device.

[0251] The steps for performing secure authentication can be implemented according to various embodiments. The request for authentication can be initiated on the user side. In some embodiments, the user may initiate a request for secure authentication to complete the transaction. For example, during the transaction or login process, the user (eg, by pressing a button on the user device or touching the touch screen) to indicate his or her intention to initiate secure authentication for the transaction or login process. User input can be sent. In some embodiments, the request for a secure authentication event may be initiated from the user device. In some examples, the request for secure authentication may be initiated from an external device such as an authentication server system. In some examples, the request for secure authentication may be initiated by a third party entity.

[0252] During the initial registration of a user account with the authentication server system, the user may register related account settings in order to request secure authentication for activities related to that user account. During subsequent activities, the authentication server system may be aware of transaction requests or login processes associated with user accounts. In response to a transaction request, the authentication server system can send a request for secure authentication to complete the transaction or login process. During registration and / or subsequent account activity, the user may register to require authentication for all activities or some activities with certain conditions.

[0253] During the initial registration of a user account with a third party entity, the user may register the relevant account settings in order to request secure authentication for activities related to that user account. For example, during the initial setup of a user account for activating or managing a card on a bank's website or within a bank's application, the user may choose to perform secure authentication for one or more transactions. During subsequent transactions, if a third-party transaction entity recognizes that a transaction related to the user account has been requested, secure authentication is required to complete the transaction using the card. During registration and / or subsequent account activity, the user may register to require authentication for all activities or some activities with certain conditions.

[0254] As described elsewhere herein, secure authentication may require analysis of nonce data and identification data. Secure authentication may be required or offered as an option by the authentication server system for one or more activities. In some embodiments, secure authentication may be requested by a third party entity. For example, a banking system or an intermediary system is secure to complete all or specific transactions (eg, flagged transactions, transactions above a given limit or randomly selected transactions). It may need to be authenticated. In some examples, secure authentication can be optional, but a third party entity rewards the user (eg, cashback or bonus reward) if the user decides to perform secure authentication and complete the transaction. Points) can be provided.

[0255] Secure authentication may be required for all or some activities related to the user account. For example, secure authentication may be required if the transaction involves an amount greater than or equal to a predetermined threshold amount. For example, the predetermined threshold amount can be $ 100, $ 200, $ 500, $ 1000, $ 5000, $ 8000, $ 10,000, $ 15,000, $ 20,000. The threshold amount can be determined by the user, the authentication server system or a third party entity. In some embodiments, secure authentication may be required if the activity is identified as a high risk activity. For example, high-risk activities can involve user accounts that are flagged for suspicious / mismatched user identification associated with user accounts, suspicious transaction locations, repeated entry of incorrect user information and / or past related fraudulent activity. .. In some embodiments, high-risk activities may involve high-speed trading, such as requiring funds to be transferred in a short period of time. Once the high-speed trading is identified, the user may request further security checks such as analysis of nonce data. In some cases, the use of additional authentication may allow online activities to take place in situations where past activities of the principal were required. Further guaranteeing the identity of the user can help reassure the entity when allowing larger transactions.

[0256] Nonce data combined with identification data can be used to authenticate transactions that exchange money, goods and / or services with third party entities. For example, a user may purchase an entity online from a third party entity (eg, e-commerce) using a user device (eg, a tablet or mobile phone). The user can authenticate on the website associated with the third party entity or within the application.

[0257] In one example, after selecting the desired item for purchase and entering the information required for the transaction (eg, the desired quantity of item and related user information), the user is to perform secure authentication. Can be prompted. For example, if a user wishes to purchase an item priced at $ 1000, the user may receive a notification requesting secure authentication on the display of the user device. The notification can require the user to scan a physical token such as a PDF417 code on the user's ID card, which scan causes nonce data to be generated for the transaction. Users can be verified or authenticated using the identification data from the PDF417 code. To ensure that the nonce data is not repeated, the nonce data can be compared with historical nonce data associated with the same physical token. If the nonce data is repeated, a warning may be issued that further certification inspection may be required or that there is a high probability of fraudulent events (eg, replay attacks). This may or may not cause the transaction to be rejected or delayed.

[0258] In some other examples, users can log in to registered user accounts on websites or within applications, such as public services, online voting systems, social networking services, etc. The user may receive notifications during the login process to perform secure authentication such as identification verification. The notification may require the user to scan a physical token, such as a graphical code, on the user's document, which scan causes nonce data to be generated for the transaction. The identification data from the graphical code can be used to validate or authenticate the user. To ensure that the nonce data is not repeated, the nonce data can be compared with historical nonce data associated with the same physical token. If the physical token is validated and the nonce data does not indicate a fraudulent indication, then the validation of the identity may be complete.

[0259] In some embodiments, the third party entity may generate a request for secure authentication according to the requirements of the third party entity or according to the user account settings registered with the third party entity. The third party trading entity may send the request to the user device to display it. The request can prompt the user to scan a graphical code such as a QR code displayed on the graphical user interface. The nonce data is generated with a QR code scan and can be sealed with the code used for authentication.

[0260] During the login process or any other type of authentication event, secure authentication may be requested by the authentication server system, third party entity or user. In response to the request, nonce data can be collected and / or analyzed for static tokens. The nonce data combined with the static token is obtained and can be transmitted directly or indirectly from the user device to the authentication server system and / or a third party entity. User device information (eg, user device identifier) may also be transmitted to the authentication server system and / or third party entity for verification.

[0261] The authentication server system may store or access various historical authentication or registration information that can be used for authentication. The information may include, but is not limited to, historical nonce data, transaction data, user account information, user device identifiers or any other type of information described elsewhere herein. Third-party entities may use historical credentials or information that can be used for authentication, such as historical nonce data, transaction data, user account information, user device identifiers or any other type of information described elsewhere herein. Various sets of registration information can also be stored or accessed.

[0262] Authentication may be performed independently by the authentication server system or by a third party entity. In some examples, authentication can be done in a combined way by both systems. For example, some information such as user account information or user device identifier may be validated by a third party trading entity. On the other hand, other information such as nonce data can be verified in the authentication server system.

[0263] In some examples, a third party entity may only remember the user account information or only the user account information without accessing the user's other sensitive and / or financial information such as nonce data. Can be accessed. Thus, if authentication with a third-party entity requires authentication, the third-party entity can specify the authentication server system to authenticate. The authentication server system can then authenticate and return a message to the third party trading entity indicating whether the authentication was approved. The authentication server can return a message based on analyzing nonce data about a particular authentication event. The transaction may then be approved or rejected by a third party entity accordingly.

[0264] In some embodiments, the authentication server system may be optional within the authentication system. A separate third party entity may perform any or all steps of authentication.

[0265] In some embodiments, the authentication server system can simultaneously perform authentication for multiple authentications for different activities. The authentication server system can simultaneously authenticate for multiple separate third party entities. Information stored in or accessible to the authentication server system can be collected across multiple transactions related to various third party entities. For example, nonce data related to various third party entities may be accessible by the authentication server system. This may allow intelligence gathered from multiple transactions to be used in authenticating. The authentication server system may access a data repository that may not be individually accessible to third party entities.

[0266] The authentication server system and / or a third party entity can analyze the received information and compare the received information with the corresponding information obtained from historical authentication and / or registration. The comparison may include a comparison of nonce data. Based on the results of the comparison, the user's login or transaction may be approved or rejected, or flagged as risk authentication / login. When login or authentication is approved, denied, or flagged, the user may be notified by the authentication server system or a third party entity.

[0267] There may be various embodiments for assessing the match between the collected data and the historical authentication or registration data. In some examples, if the data collected from the card reader matches the corresponding historical authentication or registration data, a message to approve the authentication may be sent to the third party trading entity. In some examples, if the nonce data (and / or one or more nonce factors of the nonce data) do not match, the authentication may be approved.

[0268] For example, the collected nonce data may need to be at least slightly different from the previously stored set of nonce data associated with the user and / or physical token. In some cases, a perfect 100% match can be suspicious. For example, there is likely to be some slight variation each time a physical token is imaged to perform authentication. It is highly unlikely that the imaging device and imaging data will have exactly the same conditions and characteristics. Having exactly the same conditions and characteristics can be a kind of indicator of a replay attack.

[0269] Fraudulent instructions may be provided in response to an analysis of authentication that may include analyzing nonce data (and optionally further analysis of other factors). Fraudulent instructions can relate to replay attack instructions. As explained earlier, fraud instructions can provide instructions on fraud risk levels. The fraud risk level may optionally rely on analysis of nonce data. The fraud risk level may depend on whether the collected nonce data matches the historical nonce data. The fraud risk level may depend on how closely the nonce data matches the historical nonce data and / or which nonce factor matches. For example, if the nonce data is 100% consistent for all factors, the fraud risk level can be very high. If the nonce data are almost the same but one of the nonce factors is different, the fraud risk level may be medium, and if most or none of the nonce factors match, the fraud risk level may be low. .. The fraud risk level can be proportional to how high the nonce data match is. Higher matches (eg, more factors than matches) can correlate to higher fraud risk, and lower matches can correlate to lower fraud risk.

[0270] In some embodiments, analysis of nonce data may relate to the likelihood of a replay attack. Other types of fraud analysis may be performed on the transaction. For example, fraud analysis may include assessing the likelihood of replay attacks as well as other types of fraud attacks (eg phishing, intervener attacks, etc.). Other data, such as data relating to user devices, user accounts, transaction data or any other type of data described elsewhere herein, may be analyzed to detect different types of fraud. Depending on the fraud analysis, authentication may or may not be confirmed for the user and / or the user device. This may optionally allow the transaction to be completed or delayed or rejected.

[0271] Although specific implementations have been illustrated and described, it should be understood from the above that various modifications can be made to those implementations and are expected herein. Furthermore, it is not intended that the invention is limited by the embodiments provided herein. Although the present invention has been described above with respect to the present specification, it is not intended that the description and figures of the preferred embodiments of the present specification be construed in a limited sense. Furthermore, it should be understood that all aspects of this specification are not limited to the particular depictions, configurations or relative ratios described herein, which depend on various conditions and variables. Various modifications in the form and details of the embodiments herein will be apparent to those of skill in the art. Therefore, the present invention is considered to include any such modified, modified and equivalent forms.

Claims (20)

Capturing user image data using a user device,
Obtaining identification information about the user from the image data,
Collecting nonce data including the characteristics of the image data unique to the user device at a certain point in time while the nonce data is collected, and (1) the identification information, and (2) the nonce data. Based on, including authenticating a user or transaction using one or more processors.
The image data is a method for authenticating a user or transaction, comprising at least a portion of the user's face. The method according to claim 1, wherein the nonce data further includes a checksum value derived from the image data. The method according to claim 2, wherein the checksum value is derived based on the characteristics of the image data. The characteristics of the image data are (i) one or more parameters brought about during image processing, (ii) one or more properties of the unprocessed image data, and (iii) the processed image. The method of claim 1, comprising at least one of one or more properties of the data. The method of claim 1, wherein the nonce data further includes a checksum value derived from the physical state of the user device. 5. The physical state of the user device includes data indicating the physical state of a component of the user device, wherein the component is selected from the group including an image pickup device, a power supply unit, a processor and a memory. The method described in. The method of claim 5, wherein the physical state of the user device is obtained using sensor data collected by one or more sensors. The method of claim 1, wherein the nonce data is encrypted so that when the nonce data contains two or more factors, the factors are not accessible by the one or more processors. The method of claim 1, wherein the nonce data and identification information are compared with previously collected nonce data and previously collected identification information to determine the presence of a replay attack. The method according to claim 1, wherein the image data of the user is a live image. A server that communicates with a user device, configured to allow a user to make a transaction, said server is (i) a memory for storing a set of software instructions, and (ii) one or more. Equipped with a processor
The one or more processors
Receiving user image data from the user device,
Receiving nonce data, including the characteristics of the image data that are unique to the user device, at some point during the collection of the nonce data.
Execute the set of software instructions for obtaining identification information about the user from the image data, and (1) authenticating the user or transaction based on the identification information and (2) the nonce data. Configured to
The image data is a system for authenticating a user or a transaction, including at least a part of the user's face. The system according to claim 11, wherein the nonce data further includes a checksum value derived from the image data. The system according to claim 12, wherein the checksum value is derived based on the characteristics of the image data. 12. The system of claim 12, wherein the checksum value is derived on the board of the user device. The system according to claim 12, wherein the checksum value is derived on the board of the server. The characteristics of the image data are (i) one or more parameters brought about during image processing, (ii) one or more properties of the unprocessed image data, and (iii) the processed image. 11. The system of claim 11, comprising at least one of one or more properties of the data. 11. The system of claim 11, wherein the nonce data further includes a checksum value derived from the physical state of the user device. 17. The physical state of the user device includes data indicating the physical state of a component of the user device, wherein the component is selected from the group including an image pickup device, a power supply unit, a processor and a memory. The system described in. 17. The system of claim 17, wherein the physical state of the user device is obtained using sensor data collected by one or more sensors. The system according to claim 11, wherein the image data of the user is a live image.

Images