WO2012114601A1 - 情報処理装置、及び情報処理プログラム - Google Patents
情報処理装置、及び情報処理プログラム Download PDFInfo
- Publication number
- WO2012114601A1 WO2012114601A1 PCT/JP2011/078447 JP2011078447W WO2012114601A1 WO 2012114601 A1 WO2012114601 A1 WO 2012114601A1 JP 2011078447 W JP2011078447 W JP 2011078447W WO 2012114601 A1 WO2012114601 A1 WO 2012114601A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- long
- data
- original data
- term signature
- signature
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
- G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
Definitions
- the present invention relates to an information processing apparatus and an information processing program, for example, to processing long-term signature data.
- the electronic signature is encrypted by encrypting the electronic data with a private key, and the electronic data is verified by decrypting with the public key corresponding to the private key.
- Electronic signatures are widely used.
- decrypting the electronic data with the public key it can be confirmed that the electronic data is encrypted with the private key corresponding to the public key, but the signer has the private key. It can be determined that the electronic data is from the signer.
- the private key functions as a seal
- the public key functions as a seal certificate.
- the public key is distributed by a public key certificate issued by a certificate authority, and those who have received the distribution can check the authenticity of the public key by the certificate.
- an expiration date is set for the electronic signature in order to cope with the compromise of the encryption algorithm used for the signature or the like. Even before the expiration date, all certificates below the root certificate may be revoked due to the signer's convenience or the leakage of the private key.
- an electronic signature format hereinafter referred to as a long-term signature format for perpetuating the validity of the electronic signature is defined.
- the electronic data and electronic signature to be stored are given an archive time stamp that is a time stamp with a longer expiration date than the electronic signature, so that the electronic signature can be stored even after the expiration date of the electronic signature. Guarantee the validity of the data.
- the expiration date is extended by giving a second generation archive time stamp having a longer expiration date than the archive time stamp.
- the fourth generation by extending the expiration date to the third generation, the fourth generation,..., It becomes possible to verify the non-falsification of the electronic data over a long period of time.
- the document management system may input original data to be subject to long-term signature to the long-term signature system and return the long-term signature data subjected to long-term signature processing to the document management system.
- document management systems manage original data with various attribute values such as date and importance (confidential, confidential, publicly known), but these attribute values are not signed for a long time. there were. For example, there may be a case where it is proved that the subject long-term signed data has been confidential from the past. Therefore, there is a request that these attribute values should be linked to long-term signature data to be subject to long-term signature. there were.
- the object of the present invention is to perform long-term signature on attribute information together with original data.
- original data acquisition means for acquiring original data
- setting means for setting attribute information for the acquired original data
- correspondence between the acquired original data and the set attribute information There is provided an information processing apparatus comprising: association means for attaching, and long-term signature data acquisition means for acquiring long-term signature data obtained by applying a long-term signature to the associated original data and attribute information.
- the invention according to claim 2 further comprises storage means for storing the acquired original data, the set attribute information, and the acquired long-term signature data in association with each other.
- An information processing apparatus is provided.
- the storage means stores one data generated from the original data, the attribute information, and the long-term signature data. Providing the device.
- an information processing apparatus according to the third aspect, further comprising presentation means for reading and presenting the attribute information from the first data.
- the invention according to claim 5 is characterized in that the association means associates the original data with the attribute information by generating one data from the acquired original data and the set attribute information.
- An information processing apparatus according to any one of claims 1 to 4 is provided.
- the original data acquisition function for acquiring original data, the setting function for setting attribute information for the acquired original data, and the acquired original data and the set attribute information are associated with each other.
- an information processing program that realizes a matching function for attaching, and a long-term signature data acquisition function for acquiring long-term signature data obtained by applying a long-term signature to the associated original data and attribute information by a computer.
- the present invention can perform long-term signature on attribute information together with original data by combining the original data and attribute information into a long-term signature.
- FIG. 1 is a diagram for explaining the outline of the present embodiment.
- the numbers with parentheses indicate the order of processing, and will be described below according to the order of the processing.
- the long-term signature registration system 8 sets an attribute value group for original data by receiving an input of an attribute from a user. Then, the long-term signature registration system 8 compresses the original data and the attribute value group so as to generate one long-term signature compressed data.
- the long-term signature registration system 8 outputs the long-term signature compressed data to the long-term signature system 1 for registration.
- the long-term signature system 1 obtains original data and attribute value groups by decompressing the compressed data for long-term signature.
- the long-term signature system 1 performs a long-term signature on a pair (group) of original data and attribute value group, and creates XAdES (long-term signature data) for the pair of original data and attribute value group.
- the long-term signature system 1 compresses the original data, the attribute value group, and the XAdES so as to create one long-term signature set data.
- the long-term signature system 1 outputs and registers the created long-term signature set data to the document management system 9. When the long-term signature set data is registered, the document management system 9 stores and manages this data. Alternatively, this may be decompressed and managed by associating the original data, the attribute value group, and the XAdES.
- FIG. 2 is a diagram for explaining the configuration of the long-term signature system 1, the long-term signature registration system 8, and the document management system 9.
- the long-term signature system 1 includes a long-term signature server 2, a client terminal 3, a time stamp server 5, repository servers 6, 7 and the like that are communicably connected via the Internet 4.
- the long-term signature server 2 includes a CPU (Central Processing Unit) 21, a ROM (Read Only Memory) 22, a storage unit 23, an input / output I / F 24, a RAM (Random Access Memory) 25, a display unit 26, and a communication control unit 27. It is configured.
- CPU Central Processing Unit
- ROM Read Only Memory
- RAM Random Access Memory
- the CPU 21 is a central processing unit that performs information processing and control of each unit of the long-term signature server 2 according to a program stored in the storage unit 23 or the like.
- long-term signature data is created while communicating with the client terminal 3, the time stamp server 5, and the repository servers 6 and 7.
- the ROM 22 is a read-only memory, and stores basic programs and parameters for the long-term signature server 2 to operate.
- the RAM 25 is a readable / writable memory, and provides a working memory for the long-term signature server 2 to create long-term signature data by communicating with the client terminal 3 and the like.
- the storage unit 23 is configured using, for example, a large-capacity storage device such as a hard disk, and stores an OS (Operating System) for operating the long-term signature server 2, a program for generating long-term signature data, and the like.
- the display unit 26 includes a display device using, for example, a liquid crystal or a CRT (Cathode Ray Tube), and displays various screens for an operator in charge of the long-term signature server 2 to operate the long-term signature server 2. .
- the input / output I / F 24 includes, for example, input / output devices such as various operation switches, a keyboard, and a mouse, and an operator or the like can operate the long-term signature server 2 from the input / output I / F 24.
- the communication control unit 27 communicates with the client terminal 3, the time stamp server 5, the repository servers 6 and 7, etc. via the Internet 4.
- the Internet 4 may be another form of communication network.
- the long-term signature server 2 receives an electronic signature value and original data from the client terminal 3 by the communication control unit 27, a hash value (hereinafter referred to as an attribute value original hash value) of an attribute value group set thereto, a public key certificate, etc. Can be received.
- the client terminal 3 includes a CPU 31, a ROM 32, a storage unit 33, a communication control unit 34, a RAM 35, a display unit 36, an input / output I / F 37, and the like.
- the client terminal 3 constitutes a part of the long-term signature system 1 by cooperating with the long-term signature server 2 and also constitutes a long-term signature registration system 8 and a document management system 9 independently.
- the CPU 31 is a central processing unit that performs information processing and control of each unit of the client terminal 3 in accordance with a program stored in the storage unit 33 or the like.
- input of attribute values is accepted, an attribute value group is set in the original data (long-term signature registration system 8), various types of information are transmitted to and received from the long-term signature server 2, electronic signatures using a secret key, etc. (Long-term signature system 1) or store the original data and the attribute value group on which the long-term signature is made (document management system 9).
- the ROM 32 is a read-only memory, and stores basic programs and parameters for operating the client terminal 3.
- the RAM 35 is a readable / writable memory. For example, when the client terminal 3 sets an attribute value group in the original data, or when the client terminal 3 communicates with the long-term signature server 2, the electronic signature and the attribute value original hash value are stored. Is provided, or when the client terminal 3 manages original data and attribute value groups that have been signed for a long time, a working memory is provided.
- the storage unit 33 is configured using, for example, a large-capacity storage device such as a hard disk, and an OS for operating the client terminal 3, a secret key for performing an electronic signature, and a public key corresponding to the secret key Public key certificates, original data and attribute value groups that are subject to long-term signatures are stored.
- a large-capacity storage device such as a hard disk
- an OS for operating the client terminal 3
- a secret key for performing an electronic signature
- a public key corresponding to the secret key Public key certificates
- original data and attribute value groups that are subject to long-term signatures are stored.
- As the original data for example, in addition to an electronic document created by a word processor or a text editor, various data files such as image data and audio data are possible.
- the program for the client terminal 3 to create long-term signature data in cooperation with the long-term signature server 2 may be configured to be downloaded from the long-term signature server 2 each time it is created, or stored in advance. It is also possible to store the information in the unit 33 and use it.
- the display unit 36 includes a display device using, for example, a liquid crystal or a CRT, and displays various screens for the user of the client terminal 3 to operate the client terminal 3.
- the input / output I / F 37 includes input / output devices such as a keyboard, a mouse, and an IC card reader / writer.
- the IC card reader / writer connects the IC card and mediates communication between the client terminal 3 and the IC card.
- the IC card is an information processing device including a CPU, ROM, RAM, EEPROM (Electrically Erasable and Programmable ROM), and stores, for example, user authentication information for authenticating a user who uses the client terminal 3. Yes.
- the client terminal 3 can be configured to store a private key, a public key certificate, and the like in an IC card and digitally sign using the private key of the IC card.
- the communication control unit 34 communicates with the long-term signature server 2 via the Internet 4. Transmission of a hash value, transmission of an electronic signature value, etc. to the long-term signature server 2 is performed using the communication control unit 34.
- the time stamp server 5 is a server that issues time stamps, and is installed in a TSA (Time Stamping Authority).
- the time stamp server 5 has an accurate clock that is corrected according to the time distributed by the time distribution station.
- the time stamp server 5 receives electronic data to be issued as a time stamp, the time stamp server 5 adds the current date and time by the clock.
- a time stamp is issued by electronic signature (encryption) with a time stamp private key.
- the repository server 6 is a server installed in a TSA-CA (Time Stamping Authority Certificate Authority), which corresponds to a public key certificate (corresponding to a secret key used for time stamp) used for time stamp verification. Revocation information of public key certificate) is provided. Since public key certificates not listed in the revocation information have not been revoked, it is possible to confirm the validity of the public key certificate and confirm the validity of the time stamp with the valid public key certificate. it can.
- TSA-CA Time Stamping Authority Certificate Authority
- the repository server 7 is a server installed in a CA (Certificate Authority) and is a public key certificate (public key corresponding to a private key of the client terminal 3) used for verification of an electronic signature performed by the client terminal 3. Certificate revocation information. Since the public key certificate not listed in the revocation information has not been revoked, the validity of the public key certificate is confirmed by this, and the validity of the electronic signature performed by the client terminal 3 using the valid public key certificate is confirmed. Sex can be confirmed.
- the revocation information provided by the repository server 6 and the repository server 7 is updated regularly or irregularly (for example, every 24 hours).
- FIG. 3 is a diagram showing an example of a registration screen displayed on the client terminal 3 by the long-term signature registration system 8.
- the registration screen has areas of “target file name”, “file name conversion process”, “related information”, “reference”, and “process execution”.
- “Target file name” is an area for designating original data whose file name is to be changed.
- the data after scanning is generally automatically given a file name, so specify the original data to be converted to the file name defined by the user in that area To do.
- original data “09-J-24.pdf” is designated. In this manner, original data to be processed can be registered in the registration application.
- the “Select file” button is a button for listing files and selecting the target original data.
- the “Open for content confirmation” button displays the contents of the selected original data for confirmation. It is a button for displaying.
- the “Increment serial number for each file selection” check box is a box for selecting whether or not to automatically add a serial number that increases by 1 to the selected file.
- the “file name conversion process” is an area for setting a file name after conversion.
- the file name set by the user in each item of “1.
- Product code / development code” to “6. Contents (history)” below is displayed.
- Product code / development code a product code or a development code is selected from a drop-down menu.
- Step for example, the stage where the original data is located, such as prior examination or approval, is selected from the drop-down menu.
- Material code a code representing the position of original data as a material is selected from a drop-down menu.
- Serial number a serial number to be added to the file name of the original data can be set.
- the “+” button increments the serial number by 1
- the “ ⁇ ” button increments the serial number by 1. It can be decremented and reset to the initial value “1” with the “reset” button.
- the version number of the original data is selected from a drop-down menu.
- “Related information” is an area for setting an attribute value to be attached to original data.
- creation date the date when the original data was created is selected from a drop-down menu.
- Security level the security level of the original data is selected from a drop-down menu.
- “Reference” is an area for selecting a file to be referred to after execution of the process.
- the “Open processed folder” button is a button for opening the folder (directory) in which the original data before the long-term signature that has been processed is stored, and the “Open list” button is the long-term signature that has been processed A button that opens a list of data.
- “Process execution” is an area for registering compressed data for long-term signature as a long-term signature target.
- the client terminal 3 converts each attribute value set in “Related Information” into a text file having the attribute value as a file name (described later), and a predetermined compression method ( For example, the compressed data for long-term signature is generated by the compression by the ZIP method.
- the long-term signature registration system 8 stores the long-term signature compressed data in the long-term signature target folder and registers it in the long-term signature system 1.
- FIG. 4 is a diagram for explaining the configuration of the long-term signature compressed data.
- the long-term signature compressed data is formed by storing an attribute value group and original data in a predetermined folder and compressing the attribute value group and original data. More specifically, each attribute value is set as the file name of the text file, such as “Top Secret.txt”. The contents of the text file may contain attribute values.
- These attribute value name files and the original data “CJ-01-001-1-product plan.pdf” are stored in the same folder and are compressed together.
- the folder name can be arbitrarily set, for example, the file name of the original data.
- the reason why the original data and the attribute value group are compressed into one folder in this way is that when the long-term signature registration system 8 manages these data, and the long-term signature registration system 8 transmits the data to the long-term signature system 1. This is to prevent the original data and attribute value groups from falling apart. In addition, the data capacity can be reduced.
- the reason why the attribute value is the file name of the text file is that the title of the text file can be read even in a compressed state.
- the attribute value can be read by reading the title of the text file.
- all attribute values may be described in one attribute value file.
- a CSV (Comma Separated Values) file describing attribute values may be created.
- FIG. 5 is a diagram for explaining the format of long-term signature data (long-term signature format) generated by the long-term signature system 1.
- the long-term signature data of the present embodiment is described using an XML (Extensible Markup Language) language in accordance with the rules of XAdES (XML Advanced Electronic Signatures).
- the pre-signature XAdES data is an XML element that stores signature target data to be subjected to the electronic signature of the client terminal 3, and is composed of elements of KeyInfo, signature target property, and SignedInfo.
- An ES is generated when the client terminal 3 digitally signs the pre-signature XAdES data.
- a public key certificate of a public key corresponding to the private key used by the client terminal 3 for the electronic signature is set.
- the public key certificate includes, for example, a public key, a public key owner, a certificate authority, a certificate authority signature, and the like.
- the hash value of the public key certificate is set.
- SignedInfo includes an attribute value original hash value (original data file name and its hash value after decompression, and a set of each attribute value file name and each hash value), and a hash value of a signature target property (hereinafter referred to as a signature).
- a signature signature target property
- the ES is composed of the pre-signature XAdES data and the SignatureValue as elements.
- SignatureValue a signature value obtained by signing SignedInfo by the client terminal 3 with a secret key is set. In this way, the client terminal 3 digitally signs SignedInfo, whereby the pre-signature XAdES data is signed.
- the ES-T is composed of the ES and signature time stamp as elements.
- An STS (signature time stamp) issued to the ES is set as the signature time stamp.
- the STS is obtained by giving the current date and time to the hash value of the SignatureValue in the time stamp server 5 and digitally signing it with the private key of the time stamp server 5.
- ES-XL (ES-XLong) is composed of the above-described ES-T and verification information as elements.
- the verification information is configured using a certificate group and a revocation information group.
- the certificate group includes a public key certificate of the private key used for the signature by the client terminal 3 and a public key certificate on the certification path of the public key certificate of the private key used by the time stamp server 5 for the time stamp. Has been.
- the root certificate authority issues a self-signed certificate
- the root certificate authority issues a certificate to the child certificate authority
- the child certificate authority issues a certificate to the grandchild certificate authority
- the end certificate authority verifies the verification of the public key certificate back to the root certificate authority in a certificate trust chain in which a certificate is issued to an individual or certificate owner.
- the revocation information group is composed of revocation information of a public key certificate.
- the ES-A (1st) is configured with the ES-XL and ATS (1st) described above as elements.
- ATS (1st) (Archive Time Stamp: archive time stamp) is a first generation ATS, information for verifying ES-T, original hash value, electronic signature by client terminal 3, time stamp by time stamp server 5
- a hash value created by a predetermined method from (STS) or the like is included, and the validity of ES-XL can be verified by ATS (1st).
- ES-A (2nd) includes ES-A (1st) and ATS (2nd) as elements.
- ATS (2nd) is a second generation ATS, information for verifying ES-A (1st), original hash value, electronic signature by client terminal 3, time stamp by time stamp server 5 (STS, ATS (1st) )) And the like, the hash value generated by a predetermined method is included, and the validity of ES-A (1st) can be verified by ATS (2nd).
- ES-A (3rd) having ES-A (2nd) and ATS (3rd) as elements
- ES-A (4th) having ES-A (3rd) and ATS (4th) as elements, ... and continue the generation.
- the long-term signature data configured as described above is created as follows. First, ES-XL is created, ATS (1st) is acquired while the signature time stamp and verification information are valid, and ES-A (1st) is constructed. Then, ATS (2nd) is acquired before ATS (1st) loses its validity (before expiration of the public key certificate of the time stamp token or before expiration, or before compromise of the related cryptographic algorithm). In the same manner, the acquisition of the next generation ATS is repeated before the current ATS loses its effectiveness. In this way, ATS is given to ES-XL in time series, and long-term signature data in which the latest generation ATS is within the expiration date is obtained.
- the long-term signature system 1 can attach a long-term signature by attaching an attribute value group to the original data, and does not output confidential information such as the original data and a signature private key from the client terminal 3 to the outside.
- long-term signature data can be created by the cooperation of the client terminal 3 and the long-term signature server 2.
- the long-term signature server 2 may be configured to deposit the attribute value group, the original data, and the signature private key, and to perform all the processing in the long-term signature server 2.
- FIG. 6 is a diagram showing an example of an attribute display screen displayed on the client terminal 3 by the document management system 9.
- the document management system 9 receives the long-term signature set data compressed by combining the original data, the attribute value group, and the XAdES (long-term signature data) from the long-term signature system 1, the document management system 9 decompresses the original data, the attribute value group, Save XAdES in the respective database table.
- each value stored in the database is set in each field and displayed.
- the original data file name “CJ-01-001-1-product plan.pdf” the XAdES file name “ES-A.xml”, “creation date”, “ Each attribute value such as “confidential level” is displayed.
- FIG. 7 is a flowchart for explaining a procedure in which the long-term signature registration system 8 creates compressed data for long-term signatures. The following processing is performed by the CPU 31 of the client terminal 3 according to a predetermined program.
- the client terminal 3 acquires original data (step 5). This process is performed when the user designates original data to be subject to long-term signature and sets a file name on the registration screen (FIG. 3). Next, the client terminal 3 acquires an attribute value group attached to the original data (step 10). This process is performed by the user setting each attribute value on the registration screen.
- the subsequent processing is started when the user clicks a “registration button” on the registration screen.
- the client terminal 3 creates a folder for storing original data and attribute value groups in association (step 15).
- the client terminal 3 creates a text file with each attribute value as a file name for each attribute value, and stores the text file and the original data in the folder created in step 15 (step 20).
- the client terminal 3 compresses the folder storing the original data and the text file by a predetermined method for each folder, and creates compressed data for long-term signature consisting of a single file (step 25). Then, the client terminal 3 registers the created long-term signature compressed data in the long-term signature system 1 by storing it in the long-term signature folder.
- FIG. 8 is a flowchart for explaining the first half of the procedure in which the long-term signature system 1 generates long-term signature set data. The following processing is performed by the CPU 31 of the client terminal 3 and the CPU 21 of the long-term signature server 2 according to a predetermined program.
- the client terminal 3 monitors whether or not the long-term signature compressed data is stored in the long-term signature folder (step 30).
- the long-term signature compressed data is not stored (step 30; N)
- the monitoring is continued, and when the long-term signature compressed data is stored (step 30; Y), login such as a user name and a password is performed.
- Information is transmitted to the long-term signature server 2 (step 35).
- the login information may be transmitted automatically by storing the login information in the client terminal 3 in advance, or may be read from the IC card attached by the user to the client terminal 3, or The login screen may be displayed on the display unit 36, input by the user, and transmitted.
- the long-term signature server 2 When the long-term signature server 2 receives the login information from the client terminal 3, the long-term signature server 2 authenticates the user and thereby performs login processing, and transmits to the client terminal 3 that the login processing is completed (step 40).
- the client terminal 3 Upon confirming the completion of login, the client terminal 3 decompresses the long-term signature compressed data, extracts the original data and the attribute value group, extracts the original data file name and its hash value, and each attribute value file name and each An attribute value original hash value that is a set of hash values is calculated. Then, the client terminal 3 transmits the public key certificate of the private key for signature and the attribute value original hash value to the long-term signature server 2 (step 45).
- the long-term signature server 2 When the long-term signature server 2 receives the public key certificate and the attribute value original hash value from the client terminal 3, it generates SignedInfo using this and sends it to the client terminal 3 (step 50). When the client terminal 3 receives the SignedInfo from the long-term signature server 2, it digitally signs it with the signature private key (step 55). Then, the client terminal 3 transmits the signature value based on the electronic signature to the long-term signature server 2 (step 60).
- the long-term signature server 2 When the long-term signature server 2 receives the signature value, the long-term signature server 2 sends a time stamp request for the signature value to the time stamp server 5 to issue an STS for each signature value. Receive and obtain (step 65). When access is concentrated on the time stamp server 5 and the long-term signature server 2 cannot access the time stamp server, the long-term signature server 2 designates a waiting time for the client terminal 3 (for example, 10 minutes), The client terminal 3 can be configured to retry access at a specified time.
- the long-term signature server 2 creates an ES from the public key certificate, SignedInfo, signature value, and the like previously transmitted by the client terminal 3, and creates an ES-T by adding the STS obtained from the time stamp server 5 to the ES. (Step 70).
- the long-term signature server 2 stores the created ES-T in a predetermined directory.
- the long-term signature server 2 determines the signature value used in the stored ES-T, the public key certificate necessary for verification of the STS, and the revocation information, and periodically accesses the repository servers 6 and 7. Collect these public key certificates and revocation information.
- the long-term signature server 2 transmits the ES-T (the same as that stored in the predetermined folder) and the ES-T ticket to the client terminal 3 (step 75).
- the ES-T ticket includes information for specifying the time at which the client terminal 3 starts subsequent processing, information for specifying the XAdES that is the processing target when the long-term signature server 2 resumes the subsequent processing, and the like. include.
- the client terminal 3 receives and stores these pieces of information from the long-term signature server 2 (step 80).
- This suspension period is a time when the revocation information or the like is updated in the repository servers 6 and 7, and is about 24 hours, for example.
- the reason for providing the suspension period in this way is to earn time until the revocation information provided by the repository servers 6 and 7 is updated to the latest one. That is, when the client terminal 3 digitally signs or the time stamp server 5 issues an STS, the revocation information or the like has not yet been updated even though the public key certificate has been revoked. This is to avoid it.
- FIG. 9 is a flowchart for explaining the second half of the procedure for generating the long-term signature set data in the long-term signature system 1.
- the client terminal 3 monitors whether a predetermined time designated by the ES-T ticket has elapsed (step 100). If the predetermined time has not elapsed (step 100; N), the client terminal 3 continues monitoring. On the other hand, when the predetermined time has elapsed (step 100; Y), the client terminal 3 transmits login information to the long-term signature server 2 (step 105).
- the long-term signature server 2 When the long-term signature server 2 receives the login information from the client terminal 3, the long-term signature server 2 authenticates the user and performs login processing, and transmits to the client terminal 3 that the login processing is completed (step 110). When the client terminal 3 receives the fact that the login process has been completed from the long-term signature server 2, the client terminal 3 transmits the stored ES-T ticket to the long-term signature server 2 (step 115).
- the long-term signature server 2 When the long-term signature server 2 receives the ES-T ticket from the client terminal 3, it confirms this and recognizes which XAdES the client terminal 3 is going to continue processing. Thereby, the long-term signature server 2 specifies the verification information used in the XAdES and transmits it to the client terminal 3 (step 120).
- the client terminal 3 When the client terminal 3 receives the verification information from the long-term signature server 2, the client terminal 3 embeds the verification information by adding the verification information to the ES-T and generating the ES-XL (step 125).
- the client terminal 3 generates long-term signature target data from the XAdES before the ATS (1st) is assigned, and transmits this to the long-term signature server 2 to request acquisition of ATS (1st) (step 130).
- the long-term signature target data includes, for example, information for verifying non-falsification such as original data, signature value, STS, and verification information (for example, these hash values).
- the long-term signature server 2 When the long-term signature server 2 receives the long-term signature target data from the client terminal 3, the long-term signature server 2 transmits these to the time stamp server 5, and the time stamp issued to the time stamp server 5, that is, ATS (1st). Obtain (step 135).
- the long-term signature server 2 generates XAdES-A (1st) by adding verification information and ATS (1st) to the XAdES-T stored in a predetermined directory for the XAdES to generate the client terminal 3 (Step 140).
- the client terminal 3 receives and stores XAdES-A (1st) for XAdES (step 145).
- the long-term signature system 1 generates XAdES. Thereafter, the long-term signature system 1 compresses the original data, the attribute value group, and the XAdES as a set, creates long-term signature set data, and outputs the data to the document management system 9.
- the compression procedure used here is the same as the compression procedure for the long-term signature compressed data, and the long-term signature system 1 generates a folder and stores the original data and the text file group having the attribute value as the file name in the folder. And XAdES are stored, and the entire folder is compressed.
- the long-term signature registration system 8, long-term signature system 1, and document management system 9 cooperate to set attribute values for original data, generate and manage long-term signatures for original data and attribute values consistently. be able to.
- the client terminal 3 and the long-term signature server 2 can collaborate to create long-term signature data without providing secret information such as a secret key for signature and original data outside the client terminal 3.
- XAdES is described as an example of the long-term signature method, but other methods such as PAdES (PDF Advanced Electronic Signatures) may be used.
- the client terminal 3 acquires the original data by accepting selection of the original data on the registration screen, and also sets the original data acquisition means for acquiring the original data in order to set each attribute value for the original data.
- Setting means for setting attribute information (attribute value) for original data is provided.
- the client terminal 3 since the client terminal 3 associates the original data with the attribute value group by creating the long-term signature compressed data, the client terminal 3 includes an association unit that associates the acquired original data with the set attribute information. Yes.
- one file is obtained by compression.
- the present invention is not limited to this.
- One file is not compressed, or a common number is assigned to the original data and the attribute value group. It may be linked.
- the client terminal 3 since the client terminal 3 receives the XAdES for the pair of the original data and the attribute value group from the long-term signature server 2, the client terminal 3 acquires the long-term signature data obtained by applying the long-term signature to the associated original data and attribute information. Data acquisition means are provided. For this reason, the client terminal 3 functions as an information processing apparatus including such means.
- the client terminal 3 stores the long-term signature set data in the document management system 9 to store the original data, the attribute value group, and the XAdES in association with each other, the acquired original data, the set attribute information, And storage means for storing the acquired long-term signature data (XAdES) in association with each other.
- the storage means stores the original data, the attribute information, and the long-term signature.
- One data generated from the data is stored.
- the client terminal 3 since the document management system 9 reads and displays the attribute value from the long-term signature set data, the client terminal 3 includes a presentation unit that reads and presents the attribute information from the first data.
- the client terminal 3 since the long-term signature registration system 8 associates the original data attribute value group by compressing the original data and the attribute value group into the compressed data for long-term signature, the client terminal 3 includes the association means, By generating one data from the acquired original data and the set attribute information, the original data and the attribute information are associated with each other. Note that the data may be uncompressed data, or the original data and the attribute value group may be linked by other methods.
- the client terminal 3 associates the original data acquisition function for acquiring original data, a setting function for setting attribute information for the acquired original data, and the acquired original data and the set attribute information.
- a long-term signature registration system 8 by executing an information processing program that realizes a mapping function and a long-term signature data acquisition function for acquiring long-term signature data obtained by performing long-term signature on the associated original data and attribute information by a computer
- the functions of the long-term signature system 1 and the document management system 9 are exhibited.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
電子データを公開鍵で復号化することにより、当該電子データは当該公開鍵に対応する秘密鍵で暗号化されたことを確認できるが、当該秘密鍵を有しているのは署名者であるので、当該電子データが当該署名者によるものであると認定することができる。例えるなら、秘密鍵は印鑑として機能し、公開鍵は印鑑証明書として機能している。
公開鍵は、認証局が発行する公開鍵証明書により配布され、配布を受けたものは当該証明書により公開鍵の真正を確認できるようになっている。
また、有効期限前であっても、署名者の都合で失効したり、秘密鍵の遺漏などによりルート証明書以下の全ての証明書が失効する場合もある。
そこで、この問題に対処するため、特許文献1に示されているように、電子署名の有効性を永続させるための電子署名フォーマット(以下、長期署名フォーマット)が規定されている。
そして、当該アーカイブタイムスタンプの有効期限が経過する前に、当該アーカイブタイムスタンプよりも有効期限が長い第2世代のアーカイブタイムスタンプを付与することにより有効期限を延長する。以下、第3世代、第4世代、・・・、と有効期限を延長していくことにより、電子データの非改竄性の検証が長期に渡って可能となる。
通常、文書管理システムでは、原本データに対して日付や重要度(極秘、秘密、公知)などの各種属性値を持って管理しているが、これらの属性値は長期署名されていないという問題があった。
例えば、対象の長期署名されたデータが、過去から極秘であったのかということを証明するケースも考えられるため、これらの属性値は長期署名データと紐づけて長期署名対象としたいとの要望があった。
請求項2に記載の発明では、前記取得した原本データ、前記設定した属性情報、及び前記取得した長期署名データを対応づけて記憶する記憶手段を具備したことを特徴とする請求項1に記載の情報処理装置を提供する。
請求項3に記載の発明では、前記記憶手段が、前記原本データ、前記属性情報、及び前記長期署名データから生成された1のデータを記憶することを特徴とする請求項2に記載の情報処理装置を提供する。
請求項4に記載の発明では、前記1のデータから前記属性情報を読み取って提示する提示手段を具備したことを特徴とする請求項3に記載の情報処理装置を提供する。
請求項5に記載の発明では、前記対応づけ手段が、前記取得した原本データと前記設定した属性情報から1のデータを生成することにより前記原本データと前記属性情報を対応づけることを特徴とする請求項1から請求項4までのうちの何れか1の請求項に記載の情報処理装置を提供する。
請求項6に記載の発明では、原本データを取得する原本データ取得機能と、前記取得した原本データに対して属性情報を設定する設定機能と、前記取得した原本データと前記設定した属性情報を対応づける対応づけ機能と、前記対応づけた原本データと属性情報に長期署名を行った長期署名データを取得する長期署名データ取得機能と、をコンピュータで実現する情報処理プログラムを提供する。
図1は、本実施の形態の概要を説明するための図である。括弧を付した番号は、処理の順序を示しており、以下、当該処理の順序に従って説明する。
(1)長期署名登録システム8は、ユーザからの属性の入力を受け付けることにより原本データに対する属性値群を設定する。そして、長期署名登録システム8は、原本データと属性値群がバラバラにならないように、これらを圧縮して1個の長期署名用圧縮データを生成する。
(2)長期署名登録システム8は、長期署名用圧縮データを長期署名システム1に出力して登録する。長期署名システム1は、長期署名用圧縮データを解凍して原本データと属性値群を取得する。
(4)長期署名システム1は、原本データ、属性値群、XAdESがバラバラにならないように、これらを圧縮して1個の長期署名一式データを作成する。
(5)長期署名システム1は、作成した長期署名一式データを文書管理システム9に出力して登録する。
文書管理システム9は、長期署名一式データが登録されると、これを記憶して管理する。あるいは、これを解凍し、原本データ、属性値群、XAdESを対応づけて管理してもよい。
図2は、長期署名システム1、長期署名登録システム8、文書管理システム9の構成を説明するための図である。
長期署名システム1は、長期署名サーバ2、クライアント端末3、タイムスタンプサーバ5、リポジトリサーバ6、7などがインターネット4で通信可能に接続されて構成されている。
本実施の形態では、クライアント端末3やタイムスタンプサーバ5、リポジトリサーバ6、7と通信しながら長期署名データを作成する。
RAM25は、読み書きが可能なメモリであって、長期署名サーバ2がクライアント端末3などと通信して長期署名データを作成するためのワーキングメモリなどを提供する。
表示部26は、例えば、液晶やCRT(Cathode Ray Tube)などを用いた表示装置を備えており、長期署名サーバ2の運用担当者などが長期署名サーバ2を操作するための各種画面を表示する。
通信制御部27は、インターネット4を介してクライアント端末3、タイムスタンプサーバ5、リポジトリサーバ6、7などと通信する。なお、インターネット4は、他の形態の通信網であってもよい。
長期署名サーバ2は、通信制御部27により、クライアント端末3から電子署名値や原本データと、これに設定された属性値群のハッシュ値(以下、属性値原本ハッシュ値)や公開鍵証明書などを受信することができる。
クライアント端末3は、長期署名サーバ2と協働することにより長期署名システム1の一部を構成するほか、単独で長期署名登録システム8、文書管理システム9を構成している。
本実施の形態では、属性値の入力を受け付けて、原本データに属性値群を設定したり(長期署名登録システム8)、長期署名サーバ2との各種情報の送受信、秘密鍵による電子署名などを行ったり(長期署名システム1)、長期署名が成された原本データと属性値群を保管したりする(文書管理システム9)。
RAM35は、読み書きが可能なメモリであって、例えば、クライアント端末3が原本データに属性値群を設定する場合や、クライアント端末3が長期署名サーバ2と通信しながら電子署名や属性値原本ハッシュ値の作成を行う場合、あるいは、クライアント端末3が長期署名された原本データや属性値群を管理する場合にワーキングメモリを提供する。
原本データとしては、例えば、ワープロやテキストエディタなどで作成された電子文書のほか、画像データ、音声データなどの各種のデータファイルが可能である。
ICカードリーダライタは、ICカードを接続してクライアント端末3とICカードの通信を仲介する。
ICカードは、CPU、ROM、RAM、EEPROM(Electrically Erasable and Programmable ROM)などを備えた情報処理装置であり、例えば、クライアント端末3を使用するユーザを認証するためのユーザ認証情報などが記憶されている。
また、秘密鍵や公開鍵証明書などをICカードに記憶させ、ICカードの秘密鍵を使って電子署名するようにクライアント端末3を構成することもできる。
タイムスタンプサーバ5は、時刻配信局の配信する時刻によって補正される正確な時計を有しており、タイムスタンプ発行対象となる電子データを受信すると、これに当該時計による現在日時刻を付してタイムスタンプ用の秘密鍵で電子署名(暗号化)することによりタイムスタンプを発行する。
失効情報にリストアップされていない公開鍵証明書は失効していないため、これによって公開鍵証明書の有効性を確認し、当該有効な公開鍵証明書によってタイムスタンプの有効性を確認することができる。
失効情報にリストアップされていない公開鍵証明書は失効していないため、これによって公開鍵証明書の有効性を確認し、当該有効な公開鍵証明書によってクライアント端末3の行った電子署名の有効性を確認することができる。
リポジトリサーバ6とリポジトリサーバ7が提供する失効情報は、定期・不定期(例えば、24時間ごと)に更新される。
登録画面は、「対象ファイル名」、「ファイル名変換処理」、「関連情報」、「参照」、及び「処理実行」の各エリアを有している。
ユーザが長期署名する書類をスキャナなどで読み込む場合、スキャンした後のデータには、一般に、自動的にファイル名が付与されるため、当該エリアでユーザの定義するファイル名に変換する原本データを指定する。図では、「09-J-24.pdf」なる原本データが指定されている。
このようにして、登録アプリケーションに処理対象となる原本データを登録することができる。
更に、「ファイル選択毎に追番をインクリメント」チェックボックスは、選択したファイルに1ずつ増加する追番を自動的に付与するか否かを選択するためのボックスである。
「変換後のファイル名」には、ユーザが下の「1.製品コード/開発コード」~「6.内容(履歴)」の各項目で設定したファイル名が表示される。
「2.ステップ」では、例えば、事前検討や承認済みなど、原本データの位置する段階をドロップダウンメニューで選択するようになっている。
「3.資料コード」では、原本データの資料としての位置づけを表すコードをドロップダウンメニューで選択するようになっている。
「5.Rev.」では、原本データの版数をドロップダウンメニューで選択するようになっている。
「ファイル名生成」ボタンは、変換後のファイル名を生成するためのボタンであり、クリックされると、「1.製品コード/開発コード」~「6.内容(履歴)」で入力された内容に従ってファイル名が生成され、「変換後のファイル名」に生成されたファイル名が表示される。
「1.作成日」では、原本データを作成した日をドロップダウンメニューで選択するようになっている。
「2.機密レベル」では、原本データの機密レベルをドロップダウンメニューで選択するようになっている。
「4.アクセス権」では、原本データにアクセスする権限を持っている者をドロップダウンメニューで選択するようになっている。
「5.次回更新日(見直し期間)」では、属性値を見直して更新する日をドロップダウンメニューで選択するようになっている。
「7.複製」では、複製が可能であるか否かをドロップダウンメニューで選択するようになっている。
「8.備考」では、備考をキーボードなどから入力するようになっている。
以上のようにして登録アプリケーション上で処理対象となる原本データに関する属性値(複数)を設定することができる。
「処理済フォルダを開く」ボタンは、処理実行された長期署名前の原本データが格納されたフォルダ(ディレクトリ)を開くためのボタンであり、「リストを開く」ボタンは、処理実行された長期署名データのリストを開くボタンである。
「登録」ボタンをクリックすると、クライアント端末3は、「関連情報」で設定した各属性値を、当該属性値をファイル名とするテキストファイルに変換し(後述)、原本データとともに所定の圧縮方式(例えば、ZIP方式)で圧縮して長期署名用圧縮データを生成する。
そして、長期署名登録システム8は、長期署名用圧縮データを長期署名対象用のフォルダに格納して長期署名システム1に登録する。
長期署名用圧縮データは、所定のフォルダに、属性値群と原本データを格納し、これを圧縮することにより形成されている。
より詳細には、各属性値は、「極秘.txt」などと、テキストファイルのファイル名として設定されている。テキストファイルの中身は属性値を入れてもよい。
そして、これら属性値名ファイルと、原本データ「C-J-01-001-1-製品企画書.pdf」が同じフォルダに格納され、フォルダごと圧縮されている。フォルダ名は、例えば、原本データのファイル名にするなど任意に設定することができる。
なお、属性値は、このように1つの属性値をファイル名とする1つのファイルを作成するほか、1つの属性値用ファイルの中に全ての属性値を記載してもよい。あるいは、属性値を記載したCSV(Comma Separated Values)ファイルを作成する場合も考えられる。
本実施の形態の長期署名データは、XAdES(XML Advanced Electronic Signatures)の規定に従い、XML(Extensible Markup Language)言語を用いて記述されている。
署名対象プロパティには、公開鍵証明書のハッシュ値が設定されている。
SignedInfoには、属性値原本ハッシュ値(解凍後の原本データファイル名とそのハッシュ値、および、それぞれの属性値ファイル名とそれぞれのハッシュ値の一式)、及び署名対象プロパティのハッシュ値(以下、署名対象プロパティハッシュ値)が設定されている。
SignatureValueには、SignedInfoをクライアント端末3が秘密鍵で署名した署名値が設定されている。
このように、クライアント端末3がSignedInfoに対して電子署名することにより、署名前XAdESデータに対する署名が行われる。
署名タイムスタンプには、ESに対して発行されたSTS(署名タイムスタンプ)が設定されている。STSは、タイムスタンプサーバ5において、SignatureValueのハッシュ値に現在日時刻を付与して、これをタイムスタンプサーバ5の秘密鍵で電子署名したものである。
検証情報は、証明書群と失効情報群を用いて構成されている。
証明書群は、クライアント端末3が署名に用いた秘密鍵の公開鍵証明書と、タイムスタンプサーバ5がタイムスタンプに用いた秘密鍵の公開鍵証明書の認証パス上の公開鍵証明書で構成されている。
この認証パスは、ルート認証局は自己署名証明書を発行し、そのルート認証局は子認証局に証明書を発行し、その子認証局は孫認証局に証明書を発行し、・・・、末端の認証局は、個人、証明書所有者に証明書を発行するという証明書信頼チェーンにおいて、公開鍵証明書の検証をルート認証局まで遡って確認するものである。
失効情報群は、公開鍵証明書の失効情報で構成されている。
ATS(1st)(Archive Time Stamp:アーカイブタイムスタンプ)は、第1世代のATSであって、ES-Tを検証する情報、原本ハッシュ値、クライアント端末3による電子署名、タイムスタンプサーバ5によるタイムスタンプ(STS)などから所定の方法で作成されたハッシュ値が含まれており、ATS(1st)によってES-XLの正当性を検証することができる。
ATS(2nd)は、第2世代のATSであって、ES-A(1st)を検証する情報、原本ハッシュ値、クライアント端末3による電子署名、タイムスタンプサーバ5によるタイムスタンプ(STS、ATS(1st))などから所定の方法で生成されたハッシュ値が含まれており、ATS(2nd)によってES-A(1st)の正当性を検証することができる。
図示しないが、更に、ES-A(2nd)とATS(3rd)を要素とするES-A(3rd)、ES-A(3rd)とATS(4th)を要素とするES-A(4th)、・・・と更に世代を続けることができる。
まず、ES-XLまで作成し、署名タイムスタンプと検証情報が有効なうちにATS(1st)を取得し、ES-A(1st)を構築する。
そして、ATS(1st)が有効性を失う前(タイムスタンプトークンの公開鍵証明書の有効期限切れや失効前、あるいは、関連する暗号アルゴリズムの危殆化前)に、ATS(2nd)を取得する。
以下、同様にして現在のATSが有効性を失う前に次世代のATSを取得していくことを繰り返す。
このようにして、ES-XLに対してATSが時系列的に付与され、最新の世代のATSが有効期限内である長期署名データが得られる。
なお、長期署名サーバ2に属性値群と原本データ、及び署名用の秘密鍵を預けて、長期署名サーバ2で全ての処理を行うように構成することも可能である。
文書管理システム9は、原本データ、属性値群、XAdES(長期署名データ)を組にして圧縮した長期署名一式データを長期署名システム1から受け取ると、これを解凍し、原本データ、属性値群、XAdESをそれぞれのデータベースのテーブルに保存する。
図では、文書名として「C-J-01-001-1-製品企画書.pdf」なる原本データのファイル名、「ES-A.xml」なるXAdESファイル名、及び、「作成日」、「機密レベル」、・・・などの各属性値が表示されている。
以下の処理は、クライアント端末3のCPU31が所定のプログラムに従って行うものである。
この処理は、登録画面(図3)でユーザが長期署名の対象となる原本データを指定してファイル名を設定することにより行われる。
次に、クライアント端末3は、当該原本データに付随させる属性値群を取得する(ステップ10)。
この処理は、登録画面でユーザが各属性値を設定することにより行われる。
まず、クライアント端末3は、原本データと属性値群を対応づけて格納するためのフォルダを作成する(ステップ15)。
次に、クライアント端末3は、各属性値をファイル名とするテキストファイルを属性値ごとに作成し、ステップ15で作成したフォルダに当該テキストファイルと原本データを格納する(ステップ20)。
そして、クライアント端末3は、作成した長期署名用圧縮データを長期署名用のフォルダに格納することにより長期署名システム1に登録する。
以下の処理は、クライアント端末3のCPU31と、長期署名サーバ2のCPU21が所定のプログラムに従って行うものである。
長期署名用圧縮データが格納されていない場合は(ステップ30;N)、引き続き監視を継続し、長期署名用圧縮データが格納された場合は(ステップ30;Y)、ユーザ名、パスワードなどのログイン情報を長期署名サーバ2に送信する(ステップ35)。
そして、クライアント端末3は、署名用の秘密鍵の公開鍵証明書と属性値原本ハッシュ値を長期署名サーバ2に送信する(ステップ45)。
クライアント端末3は、長期署名サーバ2からSignedInfoを受信すると、これを署名用の秘密鍵で電子署名する(ステップ55)。
そして、クライアント端末3は、当該電子署名による署名値を長期署名サーバ2に送信する(ステップ60)。
なお、タイムスタンプサーバ5にアクセスが集中しており、長期署名サーバ2がタイムスタンプサーバにアクセスできなかった場合、長期署名サーバ2がクライアント端末3に待ち時間を指定し(例えば、10分)、クライアント端末3が指定された時間にアクセスをリトライするように構成することもできる。
ES-Tチケットには、クライアント端末3が以降の処理を開始する時間を指定する情報や、長期署名サーバ2が以降の処理を再開する際に処理対象となっているXAdESを特定する情報などが含まれている。
クライアント端末3は、長期署名サーバ2から、これらの情報を受信して格納する(ステップ80)。
このように休止期間を設けるのは、リポジトリサーバ6、7が提供する失効情報が最新のものに更新されるまでの時間を稼ぐためである。即ち、クライアント端末3が電子署名したり、タイムスタンプサーバ5がSTSを発行した時点で、本来は公開鍵証明書が失効しているにもかかわらず、まだ失効情報などが更新されていない事態を回避するためである。
クライアント端末3は、ES-Tチケットで指定された所定時間が経過したか監視する(ステップ100)。
所定時間が経過していない場合(ステップ100;N)、クライアント端末3は、監視を継続する。
一方、所定時間が経過した場合(ステップ100;Y)、クライアント端末3は、ログイン情報を長期署名サーバ2に送信する(ステップ105)。
クライアント端末3は、長期署名サーバ2からログイン処理が完了した旨を受信すると、格納しておいたES-Tチケットを長期署名サーバ2に送信する(ステップ115)。
これにより、長期署名サーバ2は、当該XAdESで使用する検証情報を特定し、クライアント端末3に送信する(ステップ120)。
長期署名対象データには、例えば、原本データ、署名値、STS、検証情報などの非改竄性を検証するための情報(例えば、これらのハッシュ値)が含まれている。
クライアント端末3は、XAdESに関しては、XAdES-A(1st)を受信して保存する(ステップ145)。
その後、長期署名システム1は、原本データ、属性値群、XAdESを組にして圧縮し、長期署名一式データを作成し、文書管理システム9に出力する。
ここで用いる圧縮手順は、長期署名用圧縮データの圧縮手順と同じであり、長期署名システム1は、フォルダを生成して、当該フォルダに、原本データ、属性値をファイル名とするテキストファイル群、及びXAdESを格納し、フォルダごと圧縮する。
(1)長期に渡って証拠性を確保すべき文書管理システムにおいて、原本データと属性値をまとめて証拠化することができる。
(2)原本データの中に属性値を含めないため、原本データの再利用が可能となる。
(3)システム間でデータ群をやり取りする際に、対応するデータ群を対応づけて圧縮することにより1つのデータにすることができ、これによってデータの散逸を防止することができる。
(4)属性値をファイル名とすることにより、圧縮された状態のまま属性値を読み出すことができる。
(5)属性値を読み出して表示することによりユーザが属性値を確認・検証することができる。
(6)原本データ、属性値、XAdESを1つの証拠化ファイルとすることができ、管理が容易になる。
(7)長期署名登録システム8、長期署名システム1、文書管理システム9が連携することにより、原本データに対する属性値の設定、原本データと属性値に対する長期署名の生成、及び管理を一貫して行うことができる。
(8)署名用の秘密鍵や原本データといった秘密情報をクライアント端末3の外部に出さずにクライアント端末3と長期署名サーバ2が協働して長期署名データを作成することができる。
クライアント端末3は、登録画面で原本データの選択を受け付けることにより原本データを取得し、また、当該原本データに対する各属性値を設定するため、原本データを取得する原本データ取得手段と、前記取得した原本データに対して属性情報(属性値)を設定する設定手段を備えている。
また、クライアント端末3は、長期署名用圧縮データを作成することにより原本データと属性値群を対応づけているため、前記取得した原本データと前記設定した属性情報を対応づける対応づけ手段を備えている。
なお、実施の形態では、圧縮することにより1ファイルとしたが、これに限定するものではなく、非圧縮状態の1ファイルとしたり、あるいは、原本データと属性値群に共通の番号を付与して紐づけするなどしてもよい。
また、クライアント端末3は、長期署名サーバ2から原本データと属性値群の組に対するXAdESを受信するため、前記対応づけた原本データと属性情報に長期署名を行った長期署名データを取得する長期署名データ取得手段を備えている。
このため、クライアント端末3は、このような手段を備えた情報処理装置として機能している。
2 長期署名サーバ
3 クライアント端末
4 インターネット
5 タイムスタンプサーバ
6 リポジトリサーバ
7 リポジトリサーバ
8 長期署名登録システム
9 文書管理システム
Claims (6)
- 原本データを取得する原本データ取得手段と、
前記取得した原本データに対して属性情報を設定する設定手段と、
前記取得した原本データと前記設定した属性情報を対応づける対応づけ手段と、
前記対応づけた原本データと属性情報に長期署名を行った長期署名データを取得する長期署名データ取得手段と、
を具備したことを特徴とする情報処理装置。 - 前記取得した原本データ、前記設定した属性情報、及び前記取得した長期署名データを対応づけて記憶する記憶手段を具備したことを特徴とする請求項1に記載の情報処理装置。
- 前記記憶手段は、前記原本データ、前記属性情報、及び前記長期署名データから生成された1のデータを記憶することを特徴とする請求項2に記載の情報処理装置。
- 前記1のデータから前記属性情報を読み取って提示する提示手段を具備したことを特徴とする請求項3に記載の情報処理装置。
- 前記対応づけ手段は、前記取得した原本データと前記設定した属性情報から1のデータを生成することにより前記原本データと前記属性情報を対応づけることを特徴とする請求項1から請求項4までのうちの何れか1の請求項に記載の情報処理装置。
- 原本データを取得する原本データ取得機能と、
前記取得した原本データに対して属性情報を設定する設定機能と、
前記取得した原本データと前記設定した属性情報を対応づける対応づけ機能と、
前記対応づけた原本データと属性情報に長期署名を行った長期署名データを取得する長期署名データ取得機能と、
をコンピュータで実現する情報処理プログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/985,585 US9231766B2 (en) | 2011-02-23 | 2011-12-08 | Information processing device and information processing program |
DE112011104945T DE112011104945T5 (de) | 2011-02-23 | 2011-12-08 | Informationsverarbeitungsgerät und Informationsverarbeitungsprogramm |
CN201180068386.4A CN103370900B (zh) | 2011-02-23 | 2011-12-08 | 一种信息处理装置 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011037380A JP2012175552A (ja) | 2011-02-23 | 2011-02-23 | 情報処理装置、及び情報処理プログラム |
JP2011-037380 | 2011-02-23 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2012114601A1 true WO2012114601A1 (ja) | 2012-08-30 |
Family
ID=46720404
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2011/078447 WO2012114601A1 (ja) | 2011-02-23 | 2011-12-08 | 情報処理装置、及び情報処理プログラム |
Country Status (5)
Country | Link |
---|---|
US (1) | US9231766B2 (ja) |
JP (1) | JP2012175552A (ja) |
CN (1) | CN103370900B (ja) |
DE (1) | DE112011104945T5 (ja) |
WO (1) | WO2012114601A1 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104158662B (zh) * | 2014-07-29 | 2017-06-23 | 广东省电子商务认证有限公司 | 基于XAdES的多人电子凭证及实现方法 |
US10541817B2 (en) * | 2016-03-14 | 2020-01-21 | Ricoh Company, Ltd. | Data generation apparatus, data recording system, and program product |
CN113630363B (zh) * | 2020-05-06 | 2023-09-08 | 福建省天奕网络科技有限公司 | 分布式令牌鉴权方法、存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005148917A (ja) * | 2003-11-12 | 2005-06-09 | Ntt Data Itec Corp | 文書ワークフローシステム |
JP2009301370A (ja) * | 2008-06-16 | 2009-12-24 | Fuji Xerox Co Ltd | 電子署名管理装置及び電子署名管理プログラム |
Family Cites Families (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6959387B2 (en) * | 1996-03-21 | 2005-10-25 | Walker Digital, Llc | Method and apparatus for verifying secure document timestamping |
US6416410B1 (en) * | 1999-12-03 | 2002-07-09 | Nintendo Co., Ltd. | Data compression/decompression based on pattern and symbol run length encoding for use in a portable handheld video game system |
US7047404B1 (en) * | 2000-05-16 | 2006-05-16 | Surety Llc | Method and apparatus for self-authenticating digital records |
TW593161B (en) | 2001-08-13 | 2004-06-21 | Toray Industries | System for producing purified water |
US20050228999A1 (en) * | 2004-04-09 | 2005-10-13 | Arcot Systems, Inc. | Audit records for digitally signed documents |
JP2006059319A (ja) * | 2004-07-21 | 2006-03-02 | Ricoh Co Ltd | 情報処理装置、プログラムおよび記憶媒体 |
EP1643402A3 (en) * | 2004-09-30 | 2007-01-10 | Sap Ag | Long-term authenticity proof of electronic documents |
JP2006157399A (ja) * | 2004-11-29 | 2006-06-15 | Hitachi Ltd | 電子署名付き電子文書交換支援方法及び情報処理装置 |
US7594169B2 (en) * | 2005-08-18 | 2009-09-22 | Adobe Systems Incorporated | Compressing, and extracting a value from, a page descriptor format file |
US20070067362A1 (en) * | 2005-09-22 | 2007-03-22 | International Business Machines Corporation | Undo function for unzipped files |
JP4844281B2 (ja) * | 2006-08-10 | 2011-12-28 | 富士ゼロックス株式会社 | ドキュメント管理装置及びプログラム |
JP4929916B2 (ja) * | 2006-08-17 | 2012-05-09 | 富士ゼロックス株式会社 | 情報処理システム、情報処理装置及びプログラム |
US7774599B2 (en) * | 2006-09-15 | 2010-08-10 | Panasonic Corporation | Methodologies to secure inter-process communication based on trust |
JP4208912B2 (ja) * | 2006-10-06 | 2009-01-14 | キヤノン株式会社 | 文書検証装置およびその方法 |
US20080097786A1 (en) * | 2006-10-18 | 2008-04-24 | Rohit Sachdeva | Digital data security in healthcare enterprise |
FR2907934B1 (fr) * | 2006-10-27 | 2009-02-06 | Inst Nat Rech Inf Automat | Outil informatique de gestion de documents numeriques |
FR2912578B1 (fr) * | 2007-02-13 | 2009-05-22 | Airbus France Sas | Methode d'authentification d'un document electronique et methode de verification d'un document ainsi authentifie. |
US20090003588A1 (en) * | 2007-06-26 | 2009-01-01 | John Gordon Ross | Counter Sealing Archives of Electronic Seals |
US20090076962A1 (en) * | 2007-07-30 | 2009-03-19 | Hitchen Stephen M | Digital certification method and apparatus |
US20090201133A1 (en) * | 2007-12-03 | 2009-08-13 | Skyetek, Inc. | Method For Enhancing Anti-Cloning Protection of RFID Tags |
US8503679B2 (en) * | 2008-01-23 | 2013-08-06 | The Boeing Company | Short message encryption |
US8621222B1 (en) * | 2008-05-30 | 2013-12-31 | Adobe Systems Incorporated | Archiving electronic content having digital signatures |
JP2010050593A (ja) * | 2008-08-20 | 2010-03-04 | Nec Corp | 文書管理装置、文書管理方法および文書管理制御プログラム |
US8196203B2 (en) * | 2008-09-25 | 2012-06-05 | Symantec Corporation | Method and apparatus for determining software trustworthiness |
JP5105291B2 (ja) * | 2009-11-13 | 2012-12-26 | セイコーインスツル株式会社 | 長期署名用サーバ、長期署名用端末、長期署名用端末プログラム |
WO2012081089A1 (ja) * | 2010-12-15 | 2012-06-21 | 株式会社日立製作所 | 計算機システムの管理装置及び管理方法 |
-
2011
- 2011-02-23 JP JP2011037380A patent/JP2012175552A/ja active Pending
- 2011-12-08 DE DE112011104945T patent/DE112011104945T5/de not_active Withdrawn
- 2011-12-08 CN CN201180068386.4A patent/CN103370900B/zh active Active
- 2011-12-08 WO PCT/JP2011/078447 patent/WO2012114601A1/ja active Application Filing
- 2011-12-08 US US13/985,585 patent/US9231766B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005148917A (ja) * | 2003-11-12 | 2005-06-09 | Ntt Data Itec Corp | 文書ワークフローシステム |
JP2009301370A (ja) * | 2008-06-16 | 2009-12-24 | Fuji Xerox Co Ltd | 電子署名管理装置及び電子署名管理プログラム |
Also Published As
Publication number | Publication date |
---|---|
CN103370900A (zh) | 2013-10-23 |
US9231766B2 (en) | 2016-01-05 |
JP2012175552A (ja) | 2012-09-10 |
DE112011104945T5 (de) | 2013-11-28 |
CN103370900B (zh) | 2016-01-06 |
US20130326226A1 (en) | 2013-12-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5105291B2 (ja) | 長期署名用サーバ、長期署名用端末、長期署名用端末プログラム | |
JP5700422B2 (ja) | 長期署名用端末、長期署名用サーバ、長期署名用端末プログラム、及び長期署名用サーバプログラム | |
US20080016357A1 (en) | Method of securing a digital signature | |
US20120086971A1 (en) | System and method for electronic transmission, storage, retrieval and remote signing of authenticated electronic original documents | |
JP2003244139A (ja) | 電子文書に対するタイムスタンプ押印システム、及び、そのプログラム媒体 | |
CN105635187B (zh) | 带印模的电子文件的生成方法与装置、认证方法与装置 | |
JP5958703B2 (ja) | データ証明システムおよびデータ証明サーバ | |
US9100419B2 (en) | Long-term signature terminal, long-term signature server, long-term signature terminal program, and long-term signature server program | |
WO2012114601A1 (ja) | 情報処理装置、及び情報処理プログラム | |
KR20120112290A (ko) | 디지털 컨텐츠의 원본 생성 및 확인 시스템과 그 방법 | |
JP2005333596A (ja) | 電子申請システム、電子申請装置 | |
JP2008027089A (ja) | 電子データの開示方法およびシステム | |
EP3780487A1 (en) | System and method for electronic signature creation and management for long-term archived documents | |
JP5761683B2 (ja) | 情報処理装置、及び情報処理プログラム | |
JP2007104022A (ja) | タイムスタンプ検証システム、タイムスタンプ検証局装置およびタイムスタンプ検証方法 | |
JP2007181093A (ja) | タイムスタンプサーバ装置、及びタイムスタンプ発行方法、及びタイムスタンプ発行プログラム | |
JP5159752B2 (ja) | 通信データの検証装置及びそのコンピュータプログラム | |
JP2012239233A (ja) | 長期署名検証用サーバ、及び署名検証用サーバ | |
CN115130147A (zh) | 基于区块链的版权声明方法及版权声明装置 | |
JP2013192125A (ja) | 電子署名システム、電子署名や追記の方法 | |
CN117837124A (zh) | 通过可视化标记签署和提交电子文档的方法 | |
WO2005109207A1 (ja) | 電子ファイル時刻認証自動取得方法、および、電子ファイル時刻認証自動取得機能を備える通信端末装置 | |
JP2007310544A (ja) | 電子封筒を利用したワークフローシステム、方法、コンピュータプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 201180068386.4 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11859465 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 13985585 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 112011104945 Country of ref document: DE Ref document number: 1120111049455 Country of ref document: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 11859465 Country of ref document: EP Kind code of ref document: A1 |