Method and Apparatus for Per-Driver Driving Data Segregated Accumulation Through Issuance of Non-Identifying Cumulative Key and Session Verification Token Based on Automatic Driver Identification

Abstract

The present invention relates to a method and apparatus for separating and accumulating driving data by driver through the issuance of a non-identifying accumulation key and a session verification token based on automatic driver identification. The apparatus according to the present invention comprises: a driver identification unit that identifies a driver based on a driver seat image acquired from a driver monitoring system camera and generates a driver identification input value; a non-identifying accumulation key generation unit that generates a driver-specific non-identifying accumulation key by applying a unidirectional key derivation function to a driver identification input value and a device secret value stored in a secure area within the vehicle that is not extracted externally, and derives a server-verifiable derived value used as a criterion for driver-specific separation accumulation by an external evaluation server; a session verification token issuance unit that issues a session verification token by combining the server-verifiable derived value, time or trip metadata, a token freshness verification value, and integrity proof metadata; a transmission control unit that transmits a transmission payload to an external evaluation server; and a security module that blocks the transmission of the original driver seat image, biometric feature data, and the original value of the non-identifying accumulation key to an external network. According to the present invention, driver-specific driving data can be separated and attributed without external exposure of the driver's identity.

Description

Technology Field

[0001] The present invention relates to a technology for driver identification and driving data management within a vehicle, and more specifically, to a method and apparatus for issuing a non-identifiable token based on automatic driver identification and separating and accumulating driving data for each driver. Background Technology

[0002] Generally, conventional technology for identifying the actual driver of a vehicle relies on physical media, possession of a digital key, or vehicle-level telematics records, but recently, facial recognition using Driver Monitoring System (DMS) cameras is becoming more widespread.

[0003] However, this conventional technology has the following problems.

[0004] First, identification based on RFID cards, NFC keys, iButtons, BLE pairing keys, or digital keys is limited to the medium or key holder, so the identification result is separated from the actual driver in the event of non-carrying, rental, or unidentified operation of the card or key.

[0005] Second, conventional DMS camera-based products store biometric feature data, such as facial images, embedding vectors, and landmarks, on the cloud side, which entails a risk of external exposure of driver identity and makes it difficult to satisfy the principle of data minimization. Third, conventional identification tokens are limited to the transmission of simple identifiers or key plaintexts, making them vulnerable to forgery and replay attacks, and there is a lack of means for external servers to verify the integrity and freshness of the token issuing device. Fourth, the absence of separate processing for unregistered drivers means that their data may be mixed with that of registered drivers. Fifth, separate attribution by driver cannot be achieved when multiple drivers share the same vehicle through cumulative accumulation on a vehicle or account basis. Sixth, attribution errors occur in environments where the actual driver and the account holder do not match, such as family sharing, designated driver services, car rentals, car sharing, corporate vehicles, and peer-to-peer (P2P) rentals. The problem to be solved

[0006] The technical problem that the present invention aims to solve is to provide a method and apparatus capable of automatically identifying actual drivers using an in-vehicle camera and accurately separating and accumulating driving data for each driver while suppressing the external exposure of the driver's identity. Additionally, another objective is to verify the freshness of the token and the integrity of the issuing device, and to process the data of unregistered drivers separately from the data of registered drivers. means of solving the problem

[0007] A non-identification token issuance device according to one aspect of the present invention comprises: a driver identification unit that identifies a driver based on a driver seat image acquired from a driver monitoring system camera and generates a driver identification input value corresponding to the result; a non-identification cumulative key generation unit that generates a non-identification cumulative key that is repeatedly generated identically for the same driver by applying a unidirectional key derivation function to a device secret value stored in a secure area within the vehicle and not extracted externally, and to the driver identification input value, and derives a server verifiable derivative value used as a criterion for driver-specific separation accumulation by an external evaluation server from the non-identification cumulative key; a session verification token issuance unit that issues a session verification token by combining the server verifiable derivative value, time or trip metadata, a token freshness verification value, and integrity proof metadata; a transmission control unit that transmits a transmission payload to the external evaluation server, the server verifiable derivative value, the session verification token, and at least one of driving data, driving score, and score calculation metadata; and a security module that blocks the transmission payload from including the original driver seat image, the driver's biometric feature data, and the original value of the non-identification cumulative key in the transmission payload and transmitting it to an external network.

[0008] A method for issuing a non-identification token according to another aspect of the present invention comprises the steps of a computing device in a vehicle performing the driver identification and the generation of a driver identification input value, the generation of a non-identification cumulative key, the derivation of a server-verifiable derived value, the issuance of a session verification token, the transmission of a transmission payload, and the blocking of transmission to an external network.

[0009] A driver-specific driving data separation and accumulation system according to another aspect of the present invention comprises a computing device within a vehicle and an external evaluation server that verifies the token freshness verification value of the session verification token and the device integrity proof metadata, and, upon successful verification, separates and accumulates at least one of driving data, driving score, and score calculation metadata by driver based on the server verifiable derivative value. A method according to another aspect of the present invention comprises the step of the external evaluation server receiving and verifying the transmission payload and separating and accumulating at least one of driving data, driving score, and score calculation metadata in a driver-specific accumulation bucket corresponding to the server verifiable derivative value. Effects of the invention

[0010] According to the present invention, an actual driver is automatically identified based on an in-vehicle camera, and by combining the driver identification result with an in-vehicle device secret value that is protected from being extracted externally to generate a non-identifiable cumulative key and a server-verifiable derived value that are stably maintained for each driver, driving data can be accurately separated and accumulated for each actual driver even in an environment where multiple drivers share the same vehicle.

[0011] In addition, external exposure of driver identity can be suppressed by providing a restricted transmission payload to an external evaluation server that includes a server-verifiable derived value and a session verification token, excluding the original values ​​of the driver identification input value, facial information, and the non-identifiable accumulated key.

[0012] In addition, by combining token freshness verification values ​​and device integrity proof metadata with the session verification token, an external evaluation server can verify whether the token is reused and the trust status of the issuing device, while simultaneously securing stable identification criteria for long-term accumulation per driver and a function to prevent replay attacks per session.

[0013] In addition, by providing separate identification input values ​​and cumulative paths for unregistered drivers, the mixing of registered driver data and unregistered driver data can be prevented. Brief explanation of the drawing

[0014] FIG. 1 is a block diagram showing the overall configuration of a driver identification-based driving data separation accumulation system according to one embodiment of the present invention. FIG. 2 is a sequence diagram illustrating the operation of driver identification and driver-specific driving data separation accumulation according to an embodiment of the present invention. FIG. 3 is a flowchart illustrating the issuance flow of a non-identifiable cumulative key and a session verification token according to an embodiment of the present invention. FIG. 4 is a flowchart illustrating the operation of separating and accumulating driving data by driver on the external evaluation server side according to one embodiment of the present invention. FIG. 5 is a flowchart illustrating a branching operation for an unregistered driver according to one embodiment of the present invention. FIG. 6 is a sequence diagram showing the expiration and renewal operations of a session verification token according to one embodiment of the present invention. FIG. 7 is a flowchart showing the operation flow of an integrity proof unit according to one embodiment of the present invention. FIG. 8 is a flowchart showing the transmission payload schema verification flow of a transmission control unit according to an embodiment of the present invention. FIG. 9 is a flowchart illustrating the routing blocking and isolation storage flow of a security module according to one embodiment of the present invention. FIG. 10 is a flowchart illustrating the registration binding flow of a server verifiable derived value and a subscriber account according to one embodiment of the present invention. Specific details for implementing the invention

[0015] Then, with reference to the attached drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily implement the present invention.

[0016] The terms used herein are for describing the embodiments and are not intended to limit the invention. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text. The terms “comprises” and / or “comprising” as used in this specification do not exclude the presence or addition of one or more other components in addition to the components mentioned. Throughout the specification, the same reference numerals refer to the same components, and “and / or” includes each of the mentioned components and all combinations of one or more. Although terms such as “first,” “second,” etc., are used to describe various components, these components are not limited by these terms. These terms are used merely to distinguish one component from another.

[0017] FIG. 1 is a block diagram showing the overall configuration of a driver identification-based driving data separation accumulation system according to one embodiment of the present invention.

[0018] Referring to FIG. 1, a system according to one embodiment of the present invention may include a DMS camera (110), an in-vehicle computing device (130, hereinafter referred to as 'device'), a communication network (10), and an external evaluation server (200).

[0019] The DMS camera (110) may be an input source installed to look at the driver's seat and acquire a driver's seat image including the driver's face. The external evaluation server (200) may be connected to the device (130) via a communication network (10), and as an embodiment, may be any one of an insurance company evaluation API server, a fleet management platform, a car sharing operation server, or a rental car operation server.

[0020] The device (130) may include a driver identification unit (131), a face profile storage unit (132), a non-identifiable cumulative key generation unit (133), a session verification token issuance unit (134), a driving data collection unit (135), a transmission control unit (136), and a security module (137).

[0021] The driver identification unit (131) can generate a driver identification input value by matching the driver seat image with a pre-registered face profile in the face profile storage unit (132), or generate an unregistered driver identification input value when matching fails.

[0022] In the facial profile storage unit (132), facial profiles for N drivers (N is a natural number greater than or equal to 1) may be pre-registered through an explicit consent procedure and may be updated upon reaching a predetermined renewal expiration cycle or upon an event of reduced identification reliability.

[0023] The non-identifying cumulative key generation unit (133) can generate a non-identifying cumulative key by applying a one-way key derivation function to the device secret value and the driver identification input value, and derive a server-verifiable derived value.

[0024] The session verification token issuance unit (134) issues a session verification token and may include a token expiration / renewal unit (134a) that performs the expiration and renewal of the token.

[0025] The driving data collection unit (135) can collect driving data, driving scores, and metadata for score calculation, such as trip distance, trip period, driving behavior events, and identification reliability. Here, the identification reliability may be transmitted as a separate field of the transmission payload or included in the metadata for score calculation and transmitted.

[0026] The transmission control unit (136) transmits the transmission payload to an external evaluation server (200) and may include a schema verification unit (136a) that verifies the payload field according to a predefined schema.

[0027] The security module (137) may include a routing policy enforcement layer (137a) that controls routing to an external network interface, a secure storage area that isolates and stores biometric feature data such as original facial images, embeddings, and landmarks, a secure storage area and device keystore (137b) that stores the encryption key, device secret value, and fixed or reproducible salt, and an integrity proof unit (137c) that generates device integrity proof metadata.

[0028] The external evaluation server (200) may include a server verification and accumulation unit (210) that verifies a session verification token and separates and accumulates data by driver based on a derived value.

[0029] FIG. 2 is a sequence diagram illustrating the operation of driver identification and driver-specific driving data separation accumulation according to an embodiment of the present invention.

[0030] Referring to FIG. 2, the DMS camera (110) can acquire a driver seat image and transmit it to the driver identification unit (131) (S210). The driver identification unit (131) can look up a face profile in the face profile storage unit (132), match the face features detected from the driver seat image with the looked-up face profile (S220), and generate a driver identification input value corresponding to the result and transmit it to the non-identification cumulative key generation unit (133) (S230).

[0031] The non-identification cumulative key generation unit (133) can generate a non-identification cumulative key by applying a one-way key derivation function to the device secret value and the driver identification input value, derive a server verifiable derived value, and transmit it to the session verification token issuance unit (134) (S240).

[0032] The session verification token issuing unit (134) can receive integrity proof metadata from the integrity proof unit (137c) (S250), issue a session verification token by combining a server verifiable derived value, time or trip metadata, a token freshness verification value, and the integrity proof metadata, and provide the server verifiable derived value and the session verification token to the transmission control unit (136) (S260).

[0033] The driving data collection unit (135) can provide driving data, driving score, and metadata for score calculation to the transmission control unit (136) (S265). The transmission control unit (136) can transmit a transmission payload including at least one of the server verifiable derived value, session verification token, and driving data, driving score, and metadata for score calculation to an external evaluation server (200) (S270), and the external evaluation server (200) can verify the session verification token and then separate and accumulate at least one of the driving data, driving score, and metadata for score calculation for each driver based on the server verifiable derived value (S280).

[0034] The operations of steps S210 to S280 above may be repeated for every trip or every driving session.

[0035] FIG. 3 is a flowchart illustrating the issuance flow of a non-identifiable cumulative key and a session verification token according to an embodiment of the present invention.

[0036] Referring to FIG. 3, the non-identifiable cumulative key generation unit (133) can receive a driver identification input value and a device secret value (S310). The device secret value may be a value that is stored in a secure storage area / device key store (137b) and is not extracted externally, and optionally a local salt may be further combined, and the local salt may be stored in a fixed position or reproduced identically during the accumulation period to maintain cumulative continuity for the same driver, and may be updated according to vehicle transfer, information deletion, withdrawal of consent, or key rotation event.

[0037] The non-identifying cumulative key generation unit (133) may apply a unidirectional key derivation function to the input (S320), and as a result, a non-identifying cumulative key that is repeatedly generated identically for the same driver may be generated (S330). As an embodiment, the unidirectional key derivation function may be at least one of HMAC-SHA-256, a SHA-3 based key derivation function, or a BLAKE3 keyed hash. Here, as an embodiment, the driver identification input value may be a registration serial number determined by matching, so that the same non-identifying cumulative key can be generated for the same driver without being affected by minute variations in facial features for each trip. In the basic embodiment, the non-identifying cumulative key may be generated once at the time of registration, stored in a secure area within the vehicle, and retrieved in subsequent trips, while in other embodiments, it may be regenerated deterministically when necessary based on the same fixed input value. In any case, the original values ​​of the driver identification input value, facial profile, and non-identifying cumulative key may not be transmitted to an external evaluation server (200).

[0038] The non-identifying accumulated key generation unit (133) can derive a server-verifiable derived value from the non-identifying accumulated key (S340). The server-verifiable derived value may be a value derived by applying an additional unidirectional function, a key derivation function, or a domain-separated keyed hash to the non-identifying accumulated key, and may be generated in such a way that the external evaluation server (200) cannot reverse calculate the driver identification input value, facial profile, or the original value of the non-identifying accumulated key from the derived value, while remaining stable for the same driver. Here, 'server-verifiable' does not mean that the external evaluation server (200) reverse calculates driver identification information from the derived value, but rather that the derived value can be confirmed as a value generated from a trusted vehicle device by verifying the combined relationship between the session verification token included in the same transmission payload, the token freshness verification value combined therewith, and the integrity proof metadata. Verification of the message authentication code, digital signature, or attestation included in the session verification token may be performed by a pre-registered device public key, certificate, or shared verification key.

[0039] The session verification token issuing unit (134) may issue a session verification token by combining the server verifiable derived value with a token freshness verification value, integrity proof metadata, and time or trip metadata (S350). As an example, the token freshness verification value may include at least one of a challenge nonce issued by an external evaluation server (200), a monotonic counter managed to increase monotonically in a secure area within the vehicle, or a timestamp. The integrity proof metadata may include at least one of a report value of a secure boot measurement chain, a Trusted Execution Environment (TEE) attestation token, or a Trusted Platform Module (TPM) quote. The session verification token may be generated by any one of a keyed hash, a digital signature, or a Message Authentication Code (MAC). The server verifiable derived value and the session verification token may each be configured as separate fields of a transmission payload and transmitted.

[0040] In this specification, the term "quote" in the Trusted Platform Module (TPM) may refer to a data structure in which an integrity measurement value stored in the Platform Configuration Register (PCR) within the TPM, in accordance with the Trusted Computing Group (TCG) standard, is digitally signed with the TPM's unique authentication secret key. Additionally, the term "attestation token" (remote attestation token) in the Trusted Execution Environment (TEE) may refer to signed data issued to prove the integrity of software running within a hardware-isolated security area, and may be interpreted to include all known attestation reports or tokens commonly used in the relevant technical field.

[0041] In this specification, the reported value of the secure boot measurement chain may refer to the result of a chain of trust sequentially accumulated and recorded by verifying and measuring the integrity of each stage component (firmware, bootloader, kernel, etc.) during the system booting process, and may be interpreted to include integrity logs or measurement data values ​​generated during the measured boot process in the field of trusted computing and stored in the Platform Configuration Register (PCR), etc.

[0042] FIG. 4 is a flowchart illustrating the operation of separating and accumulating driving data by driver on the external evaluation server side according to one embodiment of the present invention.

[0043] Referring to FIG. 4, the external evaluation server (200) can receive a transmission payload from the device (130) (S410). The server verification / accumulation unit (210) can verify the token freshness verification value and the device integrity proof metadata combined with the session verification token (S420).

[0044] In one embodiment, if verification fails (S420-failure), such as when the challenge nonce is unissued, expired, or in use, or when the monotonic counter is less than or equal to the previous reception counter, or when the timestamp is outside the allowed time range, or when the TEE attestation token or TPM quote does not match the pre-registered device authentication information or the allowed secure boot measurement threshold value, the server verification / accumulation unit (210) may discard the transmission payload (S425).

[0045] If the above verification is successful (S420-success), the server verification and accumulation unit (210) can query or create a driver-specific accumulation bucket corresponding to the server-verifiable derived value (S430), and can separately accumulate at least one of driving data, driving score, and metadata for score calculation in the said bucket together with at least one of trip count, trip period, trip distance, identification reliability, and token verification result (S440). This makes it possible to separate attribution to each driver even when multiple drivers share the same vehicle.

[0046] FIG. 5 is a flowchart illustrating a branching operation for an unregistered driver according to one embodiment of the present invention.

[0047] Referring to FIG. 5, the driver identification unit (131) can match facial features with N pre-registered facial profiles (S510) and determine whether the matching is successful (S515). If the matching is successful (S515-success), a driver identification input value corresponding to the matched driver is generated (S520), a non-identifying cumulative key and a session verification token that are repeatedly generated identically for the same driver are generated (S530), and a transmission payload including a server-verifiable derived value and a session verification token, and at least one of driving data, driving score, and metadata for score calculation can be transmitted to an external evaluation server (200) (S540).

[0048] If the matching fails (S515-Failure), an unregistered driver identification input value is generated (S550), and a non-identifying cumulative key and session verification token for the unregistered driver based thereon may be generated (S560). Subsequently, whether the transmission is fraudulent may be determined (S565). If the transmission is fraudulent (S565-Yes), at least one of the non-identifying cumulative key for the unregistered driver, the server-verifiable derived value, and the session verification token may be discarded upon trip termination (S570). If the transmission is not fraudulent (S565-No), at least one of the driving data, driving score, and metadata for score calculation may be separately accumulated in a separate bucket dedicated to unregistered drivers, separated from the accumulation bucket of registered drivers (S580). Additionally, the driver identification unit (131) may exclude forged facial inputs by performing at least one of biometric sign detection, infrared image verification, depth image verification, or time continuity verification prior to the matching.

[0049] FIG. 6 is a sequence diagram showing the expiration and renewal operations of a session verification token according to one embodiment of the present invention.

[0050] Referring to FIG. 6, the token expiration / renewal unit (134a) can detect token expiration conditions, such as the end of a trip, the elapsed of a predetermined time, or the expiration of a challenge nonce (S610). When an expiration condition is detected, the token expiration / renewal unit (134a) can request re-authentication from the integrity proof unit (137c) (S620), and the integrity proof unit (137c) can verify the secure boot measurement chain and update the attestation (S630). The integrity proof unit (137c) can return the update result (S640), and a new challenge nonce can be received from the external evaluation server (200) (S650). Based on the update result and the new token freshness verification value, the token expiration / renewal unit (134a) can update the session verification token or discard the existing session verification token (S660). Meanwhile, non-identifiable accumulated keys may be maintained for long-term accumulation per driver, but may be discarded or regenerated in response to vehicle transfer, user deletion, withdrawal of consent, or key rotation events.

[0051] FIG. 7 is a flowchart showing the operation flow of an integrity proof unit according to one embodiment of the present invention.

[0052] Referring to FIG. 7, the integrity proof unit (137c) can obtain a report value of a secure boot measurement chain that links the measurement results of the boot stages of the device according to the inter-stage dependency relationship (S710), obtain a measurement value related to integrity (S720), and generate a TEE attestation token or TPM quote based on the measurement value (S730). The integrity proof unit (137c) can form integrity proof metadata by combining the TEE attestation token or TPM quote and the hash value of the secure boot measurement chain (S740), and can provide this to the session verification token issuance unit (134). The integrity proof unit (137c) can be implemented to perform the above functions, and the present invention is not limited to its specific internal division.

[0053] FIG. 8 is a flowchart showing the transmission payload schema verification flow of a transmission control unit according to an embodiment of the present invention.

[0054] Referring to FIG. 8, the transmission control unit (136) can configure the transmission payload (S810), and the schema verification unit (136a) can verify the payload fields according to a predefined transmission payload schema (S820). As an example, the schema may be limited to a field class of server verifiable derived values, session verification tokens, time or trip metadata, identification reliability, and driving data, driving scores, and metadata for score calculation.

[0055] The schema verification unit (136a) can determine whether there is a schema violation based on the result of the verification (S830). If a schema violation is detected, such as the inclusion of undefined fields, the inclusion of biometric data other than allowed fields such as original facial images, embedding vectors, and landmarks, or field type mismatch (S830-Yes), the schema verification unit (136a) can block the transmission of the corresponding transmission payload to the external evaluation server (200) (S835). If no schema violation is detected (S830-No), the transmission control unit (136) can transmit a transmission payload consisting only of allowed fields to the external evaluation server (200) through an external network interface (S840).

[0056] FIG. 9 is a flowchart illustrating the routing blocking and isolation storage flow of a security module according to one embodiment of the present invention.

[0057] Referring to FIG. 9, the security module (137) can identify a buffer in which biometric feature data, such as the original driver's seat image, a face embedding vector, or a face landmark, is stored (S910).

[0058] The routing policy enforcement layer (137a) can block the original, face embedding vector, and face landmark of the driver's seat image from being routed to the external network interface by rejecting system calls to the external network interface of the buffer at the operating system level or at the system-on-chip level (S920).

[0059] The routing policy enforcement layer (137a) may be executed in a trusted execution environment (TEE) or an equivalent security area, and the routing policy may be loaded as part of a secure boot chain and configured to prevent modification by user area processes after booting. Among the secure storage area and device keystore (137b), the secure storage area may isolate and store the original driver's seat image and biometric feature data in a non-volatile secure area within the vehicle (S930), and the device keystore may store the encryption key of the secure storage area, the device secret value, and a fixed or reproducible salt.

[0060] The present invention can be applied to environments such as fleets, rental car / car sharing, corporate vehicles, or family-shared vehicles. It overcomes the limitations of key-unit identification by automatically identifying the actual driver based on a facial profile that is pre-registered or synchronized at the time of delivery, even if multiple drivers take turns or share the same vehicle. Additionally, since the non-identifiable accumulated key per driver is based on the vehicle's device secret value, if the same driver operates multiple vehicles, different server-verifiable derived values ​​are generated for each vehicle and can be accumulated separately for each vehicle. As another embodiment, an external evaluation server (200) may bind the derived values ​​of multiple vehicles to the same subscriber's account to integrate and accumulate them on a driver-unit basis, and the present invention is not limited to any of these.

[0061] FIG. 10 is a flowchart illustrating the registration binding flow of a server verifiable derived value and a subscriber account according to one embodiment of the present invention.

[0062] Referring to FIG. 10, the non-identification token issuance structure of the present invention can be utilized in combination with registration binding on the side of an external evaluation server (200). The device (130) performs identity verification of the data subject (S1010) and can confirm that the data subject is a registered driver in the vehicle by at least one of vehicle-side facial profile matching, terminal identity verification, or combined authentication of a vehicle key and an identity verification code (S1020).

[0063] The device (130) can generate a session verification token for registration combined with a server verifiable derived value, a token freshness verification value, and integrity proof metadata (S1030), and transmit it to an external evaluation server (200) (S1040).

[0064] The external evaluation server (200) determines whether the verification of the registration session verification token is successful (S1045), and if the verification fails (S1045-No), it may deny the binding or discard the request (S1047). Meanwhile, if the verification is successful (S1045-Yes), the server may bind the verifiable derived value to a subscriber account, insurance policy, or evaluation bucket (S1050).

[0065] The above identity verification and registration binding procedure can be performed through any one of an insurance company application, an OEM application, a vehicle infotainment interface, a dealer terminal, or a repair shop terminal, and can be linked with the renewal of a session verification token by a token expiration / renewal unit (134a). Since the original values ​​of facial information, driver identification input values, and non-identification accumulated keys are not transmitted during the above process, the external evaluation server (200) may only retain the binding relationship between the subscriber identity and the derived value, and may not retain the reversible mapping with the facial biometric information.

[0066] The embodiments described above may be implemented as hardware components, software components, and / or combinations of hardware and software components. For example, the devices, methods, and components described in the embodiments may be implemented using one or more general-purpose computing devices or special-purpose computing devices, such as a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a graphics processing unit (GPU), a neural network processing unit (NPU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing device may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing device may be described as being used as a single unit, but those skilled in the art will understand that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. Other processing configurations, such as parallel processors, are also possible. The system of the present invention may operate on an embedded system-on-chip for vehicles, an electronic control unit for vehicles, or a cloud server.

[0067] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0068] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; ROMs; RAMs; flash memory; Solid-State Drives (SSDs); Non-Volatile RAMs (NVRAMs); Magnetoresistive RAMs (MRAMs); and hardware devices specifically configured to store and execute program instructions. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The above-described hardware device may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

[0069] Although the embodiments have been described above with reference to the limited drawings, those skilled in the art can apply various technical modifications and variations based on the above. For example, suitable results may be achieved even if the described techniques are performed in a different order than described, and / or if the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

Claims

Claim 1 A device for issuing a non-identification token for the separate accumulation of driving data per driver, provided within a vehicle, comprising: a driver identification unit that identifies a driver based on a driver seat image acquired from a driver monitoring system camera and generates a driver identification input value corresponding to the result of the identification; a non-identification accumulation key generation unit that generates a non-identification accumulation key that is repeatedly generated identically for the same driver by applying a unidirectional key derivation function to the driver identification input value and a device secret value stored in a secure area within the vehicle and not extracted externally, and derives a server verifiable derivative value used as a standard for the separate accumulation of driving data per driver by an external evaluation server from the non-identification accumulation key; a session verification token issuance unit that issues a session verification token by combining the server verifiable derivative value, time or trip metadata, token freshness verification value, and the integrity proof metadata of the device; and a transmission control unit that transmits a transmission payload to the external evaluation server, the server verifiable derivative value, the session verification token, the time or trip metadata, identification reliability, and metadata for driving data, driving score, and score calculation. A non-identification token issuance device comprising a security module that blocks the original of the driver's seat image, the biometric feature data of the driver, and the original value of the non-identification accumulated key from being included in the transmission payload and transmitted to an external network. Claim 2 A non-identification token issuance device according to claim 1, further comprising a facial profile storage unit that pre-registers and stores facial profiles for N drivers (N is a natural number greater than or equal to 1) in a non-volatile storage unit within a vehicle, wherein the driver identification unit generates a driver identification input value by matching facial features detected from the driver seat image with the pre-registered facial profiles of N drivers. Claim 3 A non-identification token issuance device according to claim 2, wherein the driver identification unit generates an unregistered driver identification input value when the facial features do not match any of the N facial profiles registered in the prior art, and the non-identification cumulative key generation unit processes a server verifiable derived value generated based on the unregistered driver identification input value by separating it from a server verifiable derived value corresponding to a registered driver. Claim 4 A non-identification token issuance device according to claim 1, characterized in that the unidirectional key derivation function comprises at least one of HMAC-SHA-256, a SHA-3 based key derivation function, and a BLAKE3 keyed hash. Claim 5 A non-identification token issuance device according to claim 1, characterized in that the token freshness verification value comprises at least one of a challenge nonce issued by the external evaluation server, a monotonic counter managed to increase monotonically in the security area within the vehicle, and a timestamp. Claim 6 A non-identifying token issuing device according to claim 1, characterized in that the integrity proof metadata comprises at least one of a report value of a secure boot measurement chain, an attestation token of a Trusted Execution Environment (TEE), and a quote of a Trusted Platform Module (TPM). Claim 7 A non-identification token issuance device according to claim 1, wherein the transmission control unit includes a schema verification unit that limits the fields of the transmission payload to the categories of the server verifiable derived value, the session verification token, the time or trip metadata, the identification reliability, and the driving data, driving score, and score calculation metadata according to a predefined transmission payload schema, and the security module blocks the routing of the original driver's seat image, the face embedding vector, and the face landmark to the interface of the external network at the operating system level or the system-on-chip level. Claim 8 A non-identification token issuance device according to claim 1, characterized in that the device generates a registration session verification token combined with the server verifiable derived value, the token freshness verification value, and the integrity proof metadata in response to the identity authentication of a data subject, and transmits the server verifiable derived value and the registration session verification token to an external evaluation server, excluding the driver's facial information, the driver identification input value, and the original value of the non-identification accumulated key. Claim 9 A method for issuing a non-identification token for the separation and accumulation of driving data by driver performed by an in-vehicle computing device, comprising: a step in which the computing device identifies a driver based on a driver seat image acquired from a driver monitoring system camera and generates a driver identification input value corresponding to the result of the identification; a step in which the computing device generates a non-identification accumulation key that is repeatedly and identically generated for the same driver by applying a unidirectional key derivation function to the driver identification input value and a device secret value stored in a secure area within the vehicle and not extracted externally; a step in which the computing device derives a server verifiable derivative value used as a criterion for the separation and accumulation of driving data by an external evaluation server from the non-identification accumulation key; a step in which the computing device issues a session verification token by combining the server verifiable derivative value, time or trip metadata, a token freshness verification value, and the integrity proof metadata of the computing device; and a step in which the computing device transmits a transmission payload to the external evaluation server comprising at least one of the server verifiable derivative value, the session verification token, the time or trip metadata, identification reliability, and driving data, driving score, and score calculation metadata. A method for issuing a non-identification token comprising the step of the computing device blocking the transmission of the original of the driver's seat image, the biometric feature data of the driver, and the original value of the non-identification accumulated key included in the transmission payload to an external network. Claim 10 A method for issuing a non-identification token according to claim 9, wherein the step of identifying the driver comprises the step of generating the driver identification input value by matching facial profiles of N drivers (N is a natural number greater than or equal to 1) pre-registered in a non-volatile storage within the vehicle with facial features detected from the driver's seat image. Claim 11 A method for issuing a non-identification token according to claim 10, further comprising the step of generating an unregistered driver identification input value when the facial features do not match any of the N facial profiles registered in the prior art, and processing a server-verifiable derived value generated based on the unregistered driver identification input value separately from a server-verifiable derived value corresponding to a registered driver. Claim 12 A method for issuing a non-identification token according to claim 9, wherein the blocking step comprises: a step of limiting the fields of the transmission payload to the class of the server verifiable derived value, the session verification token, the time or trip metadata, the identification confidence, and the driving data, driving score, and score calculation metadata according to a predefined transmission payload schema; and a step of blocking the routing of the original driver's seat image, the face embedding vector, and the face landmark to the interface of the external network at the operating system level or the system-on-chip level. Claim 13 A method for issuing a non-identification token according to claim 9, further comprising the steps of: the computing device generating a registration session verification token combined with the server verifiable derived value, the token freshness verification value, and the integrity proof metadata in response to the identity authentication of the data subject; and transmitting the server verifiable derived value and the registration session verification token to an external evaluation server, excluding the driver's facial information, the driver identification input value, and the original value of the non-identification accumulated key. Claim 14 A system for separating and accumulating driving data by driver, comprising: a computing device within a vehicle that identifies a driver based on a driver seat image acquired from a driver monitoring system camera; generates a non-identifying accumulated key that is repeatedly and identically generated for the same driver by applying a unidirectional key derivation function to a device secret value stored in a secure area within the vehicle and not extracted externally, and a driver identification input value corresponding to the result of the identification; derives a server verifiable derived value from the non-identifying accumulated key; and transmits a transmission payload comprising at least one of the server verifiable derived value, a session verification token combined with a token freshness verification value and device integrity proof metadata combined with the server verifiable derived value, time or trip metadata, identification reliability, and driving data, driving score, and score calculation metadata, while blocking the transmission of the original driver seat image and biometric feature data. A driver-specific driving data separation and accumulation system comprising an external evaluation server that verifies the token freshness verification value of the session verification token received from the in-vehicle computing device and the device integrity proof metadata, and, upon successful verification, separates and accumulates at least one of the driving data, driving score, and score calculation metadata included in the transmission payload for each driver based on the server verifiable derived value. Claim 15 A driver-specific driving data separation and accumulation system according to claim 14, wherein, when facial profiles for multiple drivers are pre-registered in a non-volatile storage within a vehicle, the in-vehicle computing device generates different server-verifiable derived values ​​corresponding to each driver, and the external evaluation server binds the different server-verifiable derived values ​​to individual subscriber accounts for each driver or separates and accumulates them into driver-specific sub-buckets within a single subscriber account. Claim 16 A method for separating and accumulating driving data by driver performed by an external evaluation server, comprising: a step in which the external evaluation server receives a transmission payload from a computing device in a vehicle that includes at least one of a server verifiable derived value, a session verification token, time or trip metadata, identification confidence, and driving data, driving score, and score calculation metadata; a step in which the external evaluation server verifies a token freshness verification value and device integrity proof metadata combined with the session verification token; a step in which the external evaluation server, if the verification is successful, queries or creates a driver-specific accumulation bucket corresponding to the server verifiable derived value; and a step in which the external evaluation server separates and accumulates at least one of the driving data, driving score, and score calculation metadata included in the transmission payload, together with at least one of a trip count, trip period, trip distance, identification confidence, and token verification result, into the driver-specific accumulation bucket. Claim 17 A method for separating and accumulating driving data by driver according to claim 16, wherein the verification step comprises the step of discarding the transmission payload when the challenge nonce included in the token freshness verification value is unissued, expired, or in use, or when the monotonic counter is less than or equal to a previously received counter, or when the timestamp is outside the allowed time range. Claim 18 A method for separating and accumulating driver-specific driving data according to claim 16, wherein the verifying step includes the step of discarding the transmission payload if the TEE attestation token or TPM quote included in the device integrity proof metadata does not match the pre-registered device authentication information or the allowed secure boot metric value. Claim 19 A method for separating and accumulating driving data by driver according to claim 16, further comprising the step of the external evaluation server receiving a registration session verification token linked to the identity authentication of a data subject, verifying the token freshness verification value and device integrity proof metadata combined therewith, and in response to the success of the verification, binding the server verifiable derived value to a subscriber account, insurance policy, or evaluation bucket, but not retaining a reversible mapping with the driver's facial information. Claim 20 A computer-readable non-volatile recording medium, wherein a computer program for executing on a computer a method according to any one of claims 9 to 13, or a method according to any one of claims 16 to 19, is recorded on the computer.

Images