Cryptographic processing system

Abstract

To provide a cryptographic processing system that enables per-session management in multi-access.SOLUTION: A cryptographic processing system is a cryptographic processing system having a configuration in which an application accesses a security module via software and a device driver that communicates with the software. The software issues an identifier for managing a session for each access request of the application so that access from a plurality of applications can be identified, and notifies the device driver of the identifier together with the command.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to systems for cryptographic processing. [Background technology]

[0002] Technologies related to cryptographic processing have been disclosed. Patent Document 1 discloses a cryptographic processing platform equipped with a customizable secure element. The cryptographic processing platform of Patent Document 1 allows cryptographic processing hardware to be shared between default code and custom code. The cryptographic processing platform of Patent Document 1 defines the default code and default code confidential information used by the default code as a prohibited area.

[0003] Patent Document 2 discloses a system that makes it possible to detect tampering of object code by detecting anomalies in mutual authentication or the like. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2020-201526 [Patent Document 2] Japanese Patent Application Publication No. 2019-092134 Summary of the Invention [Problem to be solved by the invention]

[0005] Cryptographic processing systems must comply with Federal Information Processing Standard 140 (FIPS140), which specifies the security requirements for security modules. Therefore, when the FIPS140 specifications are revised, it is preferable that cryptographic processing systems be implemented in accordance with the revised specifications.

[0006] An object of the present disclosure is to provide a cryptographic processing system that enables management for each session in multi-access. [Means for solving the problem]

[0007] A cryptographic processing system according to a first aspect of the present disclosure is a cryptographic processing system configured to access a security module from a device driver that communicates with an application via software, wherein the software issues an identifier for managing a session for each application access request so that accesses from multiple applications can be identified, and notifies the device driver of the identifier along with a command.

[0008] A cryptographic processing system according to a second aspect of the present disclosure is a cryptographic processing system according to the first aspect of the present disclosure, wherein the software sets a flag for managing compliance with security standards in Federal Information Processing Standards for each session, receives compliance information for the security standards as a return value from the device driver at a predetermined timing, and updates the flag based on the received compliance information.

[0009] A cryptographic processing system according to a third aspect of the present disclosure is a cryptographic processing system according to the second aspect of the present disclosure, wherein the security module executes a command created by the software and received from the device driver, and when the identifier attached to the command received from the software is a second identifier that is different from the first identifier attached to the command executed one time previously, the device driver notifies the software of a mismatch identification result including the first identifier, and when the software receives the mismatch identification result, the software sends a confirmation command to the device driver to receive the compatibility information for the notified first identifier, and the device driver sends the confirmation command to the security module to return the compatibility information obtained from the security module to the software, and sends a command of the second identifier to the security module to return the execution result of the command obtained from the security module to the software, and the software uses the compatibility information to update the flag in the session of the first identifier.

[0010] A cryptographic processing system according to a fourth aspect of the present disclosure is a cryptographic processing system according to the second aspect of the present disclosure, wherein the security module executes a command created by the software and received from the device driver, and when the identifier attached to the command received from the software is a second identifier different from the first identifier attached to the previously executed command, the device driver sends a confirmation command to the security module to receive the compatibility information of the first identifier, attaches the first identifier to the compatibility information obtained from the security module and returns it to the software, and sends a command of the second identifier to the security module and returns the execution result of the command obtained from the security module to the software, and the software uses the compatibility information to update the flag in the session of the first identifier.

[0011] A cryptographic processing system according to a fifth aspect of the present disclosure is a cryptographic processing system according to the second to fourth aspects of the present disclosure, wherein the device driver prohibits confirmation of the compatibility information and notification of the confirmation when the previously executed command is a confirmation command for receiving the compatibility information and the identifier is different.

[0012] A cryptographic processing system according to a sixth aspect of the present disclosure is a cryptographic processing system according to the second to fifth aspects of the present disclosure, wherein the software has the function of, when closing a session from the application, notifying the device driver of a confirmation command to receive the compatibility information, notifying the application of the acquired compatibility information, and then terminating the session.

[0013] A cryptographic processing system according to a seventh aspect of the present disclosure is a cryptographic processing system according to the second to sixth aspects of the present disclosure, wherein if the maximum number of simultaneous accesses allowed by the security module is exceeded or if the command is not executed normally, the software notifies the application of an access error and does not check compliance with the security standard. [Effects of the Invention]

[0014] According to the first aspect of the present disclosure, management for each session in multi-access becomes possible.

[0015] According to the second aspect of the present disclosure, it is possible to manage adaptation information for each session in multi-access.

[0016] According to the third aspect of the present disclosure, matching information corresponding to different identifiers can be acquired by multiple accesses.

[0017] According to the fourth aspect of the present disclosure, matching information corresponding to different identifiers can be acquired by multiple accesses.

[0018] According to the fifth aspect of the present disclosure, when the previously executed command is a command for receiving compatibility information, checking of compatibility information can be suppressed.

[0019] According to the sixth aspect of the present disclosure, the application can be notified of the compatibility information when the session is closed.

[0020] According to the seventh aspect of the present disclosure, it can be specified that in the event of an error, compatibility check is not performed. [Brief explanation of the drawings]

[0021] [Figure 1] FIG. 1 is a diagram illustrating a functional configuration of a cryptographic processing system. [Figure 2] FIG. 2 is a block diagram showing the hardware configuration of an information processing device that causes the cryptographic processing system to function. [Figure 3] FIG. 10 is a diagram for explaining a flow assumed in the case of single access. [Figure 4] FIG. 10 is a diagram for explaining a flow assumed in the case of multiple access in the first embodiment. [Figure 5] FIG. 10 is a diagram for explaining a flow assumed in the case of multiple access. [Figure 6] 4 is a sequence showing the flow of processing in the cryptographic processing system of the first embodiment. [Figure 7] FIG. 10 is a diagram for explaining a flow assumed in the case of multiple access in the second embodiment. [Figure 8] 10 is a sequence showing the flow of processing in the cryptographic processing system of the second embodiment. [Figure 9] FIG. 11 is a diagram for explaining a flow assumed in the case of multiple access in the third embodiment. [Figure 10] 10 is a sequence showing the flow of processing in the cryptographic processing system of the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0022] An example of an embodiment of the present disclosure will be described below with reference to the drawings. The same or equivalent components and parts in each drawing are designated by the same reference numerals. The dimensional proportions in the drawings are exaggerated for the sake of explanation and may differ from the actual proportions.

[0023] The revision from FIPS 140-2 to FIPS 140-3 requires that users (applications) be notified if encryption processing or key exchange methods using algorithms not approved by NIST (National Institute of Standards and Technology) are used. Currently, consideration is being given to the implementation of this requirement in the software aspects of information devices that are actually used.

[0024] Operations on a security module are performed by issuing a command sequence consisting of multiple commands. A command represents a unitized exchange of information such as a session ID and encryption key required for application cryptographic processing. However, verifying that each command is executed with NIST-approved parameters places a burden on the TPM processor and requires communication overhead, slowing down processing time. Furthermore, NIST-approved algorithms may contain unrelated commands, which can be inefficient. Therefore, it is preferable to check the status cumulatively. However, access requests from multiple applications are permitted to be executed simultaneously via multithreading. This has led to problems such as the software (TSS) issuing commands to access the TPM being unable to issue status commands at the appropriate time, making it difficult to read the correct status. Therefore, the cryptographic processing system of each embodiment of the present disclosure (hereinafter, the present embodiment) is implemented to enable session-by-session management in multi-access situations.

[0025] FIG. 1 is a diagram showing the functional configuration of a cryptographic processing system. As shown in FIG. 1, the cryptographic processing system 1 includes a plurality of applications 11 (11 1~n), software 12 as a TSS (TPM Software Stack), a device driver 13, and a security module 14 as a TPM. Of these, the security module 14 is hardware. The software communicates with the application 11 and the device driver 13. The device driver 13 communicates with the software 12 and the security module 14. The cryptographic processing system 1 is configured so that the application 11 accesses the security module 14 via the software 12, and the device driver 13 accesses the security module 14. The software 12 manages execution commands from the accessing application 11 using a session ID. The session ID is an example of an "identifier" in the technology of the present disclosure.

[0026] 2 is a block diagram showing the hardware configuration of an information processing device 30 that causes the cryptographic processing system 1 to function. A computer, a server, or other device may be applied to the information processing device 30. The information processing device 30 according to this embodiment includes a CPU 31, a memory 32 as a temporary storage area, a nonvolatile storage unit 33, the security module 14 described above, and a communication unit 34 that communicates with external devices. Each component is connected to one another via a bus B2.

[0027] The storage unit 33 is realized by a storage device such as an HDD, SSD, or flash memory. The storage unit 33, which serves as a storage medium, stores a cryptographic processing program 33A and various other programs. The CPU 31 reads the cryptographic processing program 33A from the storage unit 33, expands it in the memory 32, and sequentially executes the processes of the cryptographic processing program 33A. Execution of the cryptographic processing program 33A executes the processes of the application 11, software 12, and device driver 13 described above. When executing a program, the information processing device 30 uses the above hardware resources to realize various functions. As described above, the hardware configuration of the information processing device 30 realizes the various functional configurations of the cryptographic processing system 1.

[0028] [First embodiment] Common to all embodiments, the cryptographic processing system 1 is assumed to receive access requests from multiple applications 11, and multiple accesses are assumed. For comparison, the flow of single access and the flow of multiple accesses will be compared and explained. In either case of access, the software 12 issues a session ID for managing the session for each access request from the application, and notifies the device driver 13 of the session ID together with a command. The device driver 13 obtains compliance information indicating whether or not the device is FIPS compliant from the security module 14. In the case of multiple accesses, the session ID can be used to identify accesses from multiple applications 11.

[0029] The software 12 also sets a flag for each session to manage compliance with FIPS security standards. Compliance information for security standards can be acquired from the security module 14. The flag can be expressed as a binary value, such as "00," "01," or "10," and can be updated by performing an OR operation. In this case, "00" can be set as the initial value. The software 12 receives compliance information as a return value from the device driver 13 at a predetermined timing and updates the flag based on the received compliance information. An example of flag updating will be described. For example, if the compliance information acquired for session ID: 00 indicates acceptable compliance, the flag is represented by "01," and if the compliance information acquired for session ID: 01 indicates acceptable compliance, the flag is represented by "10." In this case, if compliance information for session ID: 00 is acquired, the flag can be updated to "01" by performing an OR operation of "00" and "01." The timing will be described using a sequence.

[0030] Fig. 3 is a diagram for explaining the flow assumed in the case of single access, and Fig. 4 and Fig. 5 are diagrams for explaining the flow assumed in the case of multiple access.

[0031] Single access and multiple access are outlined below. A specific sequence flow will be described later. The flow shown in Figure 4 assumes that a single access occurs from a single application 11. In the case of single access, when the software 12 receives an access request from the application 11, it issues a session ID indicating the session for that access request. The software 12 creates a command for that session (a command sequence consisting of individual commands) and sends it to the device driver 13. The device driver 13 sends the command to the security module 14. The security module 14 executes the requested command and returns the execution results to the device driver 13. After obtaining and returning the execution results of all commands, the device driver 13 obtains compliance information indicating whether or not the software is FIPS compliant and notifies the software 12. The compliance information is obtained by sending a confirmation command to receive the compliance information to the security module 14. This allows the software 12 to obtain the compliance information for that session. The software 12 closes the session and sends results including the compliance information and the command execution results to the application 11. The application 11 receives the results from the security module 14 (TPM).

[0032] The flow shown in Figures 4 and 5 assumes that multiple accesses have occurred from application 111 and application 112. In Figures 4 and 5, the session ID of application 111 is shown as "ID0," and the session ID of application 112 is shown as "ID1." The following explains the differences from single access, focusing on the main points. In the case of multiple accesses, when software 12 accepts an access request, it issues a session ID and then initializes and sets a flag for managing compatibility information for that session ID. When device driver 13 accepts a new command, it determines whether the session ID of the newly accepted command is the same as the session ID attached to the command executed immediately before. For convenience of explanation, the session ID attached to the command executed immediately before (the previous session ID) is referred to as the "first session ID." The session ID of the newly accepted command is referred to as the "second session ID." If the session IDs are not the same, it is necessary to determine that they are different session IDs and obtain compatibility information. The first session ID is an example of a "first identifier" in the technology of the present disclosure, and the second session ID is an example of a "second identifier" in the technology of the present disclosure.

[0033] In the first embodiment, if the device driver 13 determines that the session IDs are different, it notifies the software 12 of mismatched identification information including the first session ID. When the software 12 receives the notification of the mismatched identification result, it sends a confirmation command to the device driver 13 to receive the status of the compatibility information for the notified first session ID. The device driver 13 sends the confirmation command to the security module 14 and returns the compatibility information acquired from the security module 14 to the software 12. The software 12 uses the returned compatibility information to update a flag in the session for the first session ID. In addition, the device driver 13 sends a command for the second session ID to the security module 14 together with the returned compatibility information, and returns the execution result of the command acquired from the security module 14 to the software 12.

[0034] FIG. 6 is a sequence showing the flow of processing in the cryptographic processing system 1 of the first embodiment.

[0035] In S10, the application 11 sends an access request to the software 12.

[0036] In S12, the software 12 issues a session ID for managing the session of the accepted access request.

[0037] In S14, the software 12 creates a command and sends the command to the device driver 13 together with the issued session ID.

[0038] In S16, the device driver 13 determines whether the session ID attached to the received command is the same as the session ID attached to the command executed immediately before. If it is determined that they are the same, the process proceeds to S18. If it is determined that they are not the same, the process proceeds to S22, assuming that the attached session ID is a second session ID different from the first session ID. Note that if the immediately previous command has not been executed, the process proceeds to S18.

[0039] In S18, the device driver 13 sends a command to the security module 14.

[0040] In S20, the device driver 13 receives the execution result of the command from the security module 14 and returns the execution result to the software 12.

[0041] The software 12 and device driver 13 execute the processes from S14 to S20 until execution of all commands required in the session is completed. When execution of the commands is completed, the software 12 closes the session and transmits the execution results of the returned commands. When the software 12 acquires compatibility information in S22 or later, it transmits the execution results of the commands and the compatibility information, which is the execution result of the confirmation command, to the application 11.

[0042] S22 and subsequent steps are performed when the session IDs are different as determined in S16. In S22, the device driver 13 notifies the software 12 of the result of the mismatch identification including the first session ID.

[0043] In S24, the software 12 accepts the result of the mismatch identification, and thereby obtains the first session ID of the command executed immediately before.

[0044] In S26, the software 12 sends a confirmation command to the device driver 13 to receive the status of the compatibility information for the first session ID.

[0045] In S28, the device driver 13 sends a confirmation command to the security module 14.

[0046] In S30, the device driver 13 receives the execution result of the confirmation command from the security module 14 and returns the conformance information as the execution result of the confirmation command to the software 12. In this way, the timing is defined so that the software 12 receives the conformance information by the return of S30.

[0047] In S32, the software 12 updates the flag in the session with the first session ID using the returned matching information.

[0048] Furthermore, in parallel with S28, the device driver 13 transitions to S18 at (X), transmits a command for the second session ID to the security module 14, and returns the execution result of the command to the software 12. After updating the flag in S32 and receiving the result of the command for the second session ID, the software 12 closes the session. Then, after closing the session for the second session ID, it resumes creating a command for the first session ID.

[0049] Note that if the command for the first session ID is resumed after the session for the second session ID is closed, it will be determined in S16 that the session ID is different from the previous session ID. In this case, the device driver 13 determines after this process whether the previously executed command is a confirmation command. If the previously executed command is a confirmation command, the cryptographic processing system 1 executes S18 and S20 for the resumed first session ID, and then executes S26 to S32 to end the session.

[0050] In this way, if the previously executed command was a confirmation command for receiving compatibility information, the device driver 13 prohibits confirmation of compatibility information and notification of the confirmation even if the session ID is different. Furthermore, the software 12 has a function of terminating the session after notifying the application 11 of the acquired compatibility information. When closing a session from the application 11, the software 12 sends a confirmation command for receiving compatibility information to the device driver 13, acquires the compatibility information, updates the flag, and notifies the application 11.

[0051] As described above, the cryptographic processing system 1 according to the first embodiment can manage access requests in multi-access for each session and acquire matching information for each session.

[0052] [Second embodiment] 7 is a diagram for explaining the assumed flow in the case of multiple accesses in the second embodiment. In the second embodiment, notification to the software 12 when the session IDs are different is omitted, and a confirmation command is sent directly from the device driver 13 to the security module 14.

[0053] 8 is a sequence diagram showing the flow of processing in the cryptographic processing system 1 of the second embodiment. The difference from the first embodiment is that S22 to S26 in the sequence of the first embodiment of FIG. 6 are omitted.

[0054] In S40, the device driver 13 sends a confirmation command to the security module 14. In S42, the device driver 13 adds a first session ID to the compatibility information acquired from the security module 14 and returns it to the software 12.

[0055] [Third embodiment] FIG. 9 is a diagram for explaining the assumed flow in the case of multi-access in the third embodiment. The third embodiment differs from the second embodiment in that, when the session ID is different, it determines whether the immediately previous command is a confirmation command. FIG. 10 is a sequence showing the flow of processing in the cryptographic processing system 1 of the third embodiment. In S50, the device driver 13 determines whether the immediately previous command was a confirmation command. If it was a confirmation command, it transmits the command in S18 without checking the compatibility information. If it was not a confirmation command, it transmits the confirmation command in S40.

[0056] The cryptographic processing system 1 of each of the above embodiments can be modified as needed. For example, in the cryptographic processing system 1, the software 12 can be configured to notify the application 11 of an access error when an error occurs, and not check the conformance with the security standard. The error may occur, for example, when the maximum number of simultaneous accesses permitted by the security module 14 is reached, or when a command is not executed normally.

[0057] In the above embodiments, various processes executed by a CPU after reading a program may be executed by various processors other than the CPU. Examples of such processors include programmable logic devices (PLDs) whose circuit configuration can be changed after fabrication, such as field-programmable gate arrays (FPGAs), and dedicated electrical circuits, such as application-specific integrated circuits (ASICs), which are processors with circuit configurations specifically designed to execute specific processes. Furthermore, various processes may be executed by one of these various processors, or by a combination of two or more processors of the same or different types (e.g., multiple FPGAs, or a combination of a CPU and an FPGA). Furthermore, the hardware structure of these various processors is, more specifically, an electrical circuit that combines circuit elements such as semiconductor devices.

[0058] In addition, in each of the above embodiments, the programs for executing various processes are described as being stored (installed) in advance, but this is not limiting. The programs may be provided in a form recorded on a non-transitory recording medium such as a CD-ROM (Compact Disk Read Only Memory), a DVD-ROM (Digital Versatile Disk Read Only Memory), or a USB (Universal Serial Bus) memory. The programs may also be downloaded from an external device via a network.

[0059] Furthermore, the operations of the processor in each of the above embodiments may be performed not only by a single processor but also by multiple processors located at physically separate locations working together. Furthermore, the order of the operations of the processor is not limited to the order described in each of the above embodiments and may be changed as appropriate. [Explanation of symbols]

[0060] 1. Cryptographic processing system 11 Applications 12 Software 13 Device Drivers 14 Security Module 30 Information processing equipment

Claims

1. A cryptographic processing system having a configuration in which an application accesses a security module via software and a device driver that communicates with the software, The software comprises: An identifier for managing a session is issued for each access request from an application so that access from multiple applications can be identified, notifying the device driver of the identifier together with a command; setting a flag for managing compliance with security standards in Federal Information Processing Standards for each session; receiving, at a predetermined timing, conformance information of the security standard as a return value from the device driver, and updating the flag based on the received conformance information; A system for cryptographic processing.

2. the security module executes a command created by the software and received from the device driver; when the identifier attached to the command received from the software is a second identifier different from a first identifier attached to a command executed immediately before, the device driver notifies the software of a mismatch identification result including the first identifier; When the software receives the notification of the mismatch identification result, the software sends a confirmation command to the device driver to receive the compatibility information for the notified first identifier; the device driver sends the confirmation command to the security module and returns the compatibility information acquired from the security module to the software, and sends a command with the second identifier to the security module and returns the execution result of the command acquired from the security module to the software; 2. The cryptographic processing system of claim 1, wherein the software uses the matching information to update the flag in the session of the first identifier.

3. the security module executes a command created by the software and received from the device driver; When the identifier attached to the command received from the software is a second identifier different from a first identifier attached to the command executed immediately before, the device driver: Sending a confirmation command to the security module to receive the compatibility information of the first identifier, and returning the compatibility information obtained from the security module to the software together with the first identifier; Sending a command with the second identifier to the security module and returning the execution result of the command obtained from the security module to the software; 2. The cryptographic processing system of claim 1, wherein the software uses the matching information to update the flag in the session of the first identifier.

4. A cryptographic processing system described in any one of claims 1 to 3, wherein the device driver prohibits confirmation of the compatibility information and notification of the confirmation if the previously executed command is a confirmation command for receiving the compatibility information and the identifier is different.

5. When the software closes a session from the application, it sends a confirmation command to the device driver to receive the compatibility information; 5. The cryptographic processing system according to claim 1, further comprising a function of terminating a session after notifying said application of said acquired compatibility information.

6. A cryptographic processing system described in any one of claims 1 to 5, wherein if the maximum number of simultaneous accesses allowed by the security module is exceeded or if the command is not executed normally, the software notifies the application of an access error and does not check compliance with security standards.

Images