+

WO1999060749A1 - Systeme de partage d'informations - Google Patents

Systeme de partage d'informations Download PDF

Info

Publication number
WO1999060749A1
WO1999060749A1 PCT/JP1999/002510 JP9902510W WO9960749A1 WO 1999060749 A1 WO1999060749 A1 WO 1999060749A1 JP 9902510 W JP9902510 W JP 9902510W WO 9960749 A1 WO9960749 A1 WO 9960749A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
team
list
encryption
key
Prior art date
Application number
PCT/JP1999/002510
Other languages
English (en)
French (fr)
Other versions
WO1999060749A8 (fr
Inventor
Tatsuma Ohkubo
Shouichi Toyoda
Kazunari Nakane
Tetsu Saburi
Naoto Oki
Original Assignee
Mitsubishi Materials Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP10135502A external-priority patent/JPH11331145A/ja
Priority claimed from JP10227410A external-priority patent/JP2000059358A/ja
Priority claimed from JP10307658A external-priority patent/JP2000134195A/ja
Priority claimed from JP10309223A external-priority patent/JP2000137435A/ja
Priority claimed from JP10372187A external-priority patent/JP2000196583A/ja
Priority claimed from JP11029384A external-priority patent/JP2000227879A/ja
Application filed by Mitsubishi Materials Corporation filed Critical Mitsubishi Materials Corporation
Priority to EP99919583A priority Critical patent/EP1083699A1/en
Publication of WO1999060749A1 publication Critical patent/WO1999060749A1/ja
Publication of WO1999060749A8 publication Critical patent/WO1999060749A8/ja

Links

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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/321—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 a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/601—Broadcast encryption

Definitions

  • the present invention relates to an information sharing system for preventing information from being viewed or falsified, an information processing method thereof, and a recording medium for the purpose of information sharing among a plurality of users.
  • DES Data Encryption Standard
  • an object of the present invention is to provide an information sharing system and an information processing method thereof that can prevent a database that stores encrypted information, an administrator of a server, a file system, or the like from seeing or falsifying information.
  • Another object of the present invention is to provide a recording medium.
  • an object is to provide an information sharing system that employs a common key encryption method and a public key encryption method and is capable of sharing a common key with at least a group, and that is accessed by at least a plurality of members.
  • An information storage device capable of storing at least a digital signature of the team master, a member list including the public key information, a common key list including the encryption key information, and an encrypted data.
  • a storage unit that stores at least one member's public key that can be viewed, and encrypts input information based on the above common key encryption method that uses a common key for encrypting information to generate encrypted data.
  • An encryption unit for encrypting a common key used for encryption with a designated public key stored in the storage unit, and an encryption key generation unit for generating an encryption key;
  • the key and the encrypted data and the transfer section for transferring in the information storage device, said information storage device From the member list, determines whether the digital signature of the team master of the relevant member list matches the specified digital signature, and registers the public key of the member to be added only when they match.
  • the public key of the member who will be resigned is deleted, and in the case of additional registration or deletion, a new member list including at least the digital signature of the team master and member public key information is created and stored in the above information storage device
  • the desired encryption key information and encrypted data are obtained from the list management unit to be transferred and the information storage device, the common key is decrypted from the encryption key information, and the encryption obtained using the decrypted common key is obtained.
  • This can be achieved by a device called an information sharing system including an encryption / decryption device having a decryption unit for decrypting data.
  • the shared key can be shared by the group, and there is no possibility that the contents of the information can be seen by the administrator of the database storing the encrypted data, the server, and the file system.
  • the object is to provide a sender terminal installed on the sender side, and a receiver terminal connected to the sender terminal via a network and installed on the receiver side.
  • An information tampering detection device for transmitting and receiving information between the sender terminal and the receiver terminal and detecting tampering of the information, wherein the receiver terminal has received the information.
  • a reception content confirmation information creating unit that creates confirmation information
  • a transmission unit that transmits the reception content confirmation information via the network
  • the reception content confirmation information via the network is a reception content confirmation information via the network.
  • Information tampering detection device comprising: a reception unit that receives the information; and a tampering detection unit that compares the information transmitted from the sender side terminal with the reception content confirmation information and detects tampering based on the comparison result. To More it is achieved in the apparatus.
  • the object is to provide an encryption device including a key encryption unit and an encryption unit, wherein the key encryption unit uses a common key encryption method to perform encryption using a common key.
  • a common key obtaining unit that obtains or generates a common key
  • a common key encrypting unit that encrypts the common key using a public key cryptosystem and uses the common key as an encryption key, and key information that is used for detecting common key falsification from the common key.
  • a first common key falsification detection information generating unit for generating a ciphertext, wherein the encrypting unit encrypts the plaintext using the common key to form a ciphertext, and a first data falsification from the plaintext.
  • This can be achieved by a device called an encryption device comprising a first data tampering detection information creation unit for creating detection information.
  • tampering detection information is not created for each plaintext, but key information serving as tampering detection information is created for a common key that encrypts each plaintext, and tampering detection and the common key creator's Since identification is possible, the overhead of encrypted information obtained by encrypting information can be reduced. Therefore, it is possible to reduce the load on the network at the time of transferring the encrypted information and the capacity of the storage device required for storing the encrypted information. Further, according to the present invention, the object is to provide a team data list management device that manages a team data list for hierarchizing teams, and sends an operation request of the team data list to a predetermined request destination.
  • the team master of the root team by the user A team data list changing unit for making a change in accordance with the operation request to the team data list whose validity has been confirmed by the validity checking unit; and Create a digital signature of the instructor who made the request, attach the digital signature to the modified team data list, and send it to the request destination Et achieved by the apparatus of the team data list management apparatus and a digital signature unit is.
  • a sub-team can be created under each team by using a team data list including an authority list and authority data, and a hierarchical team is constructed. be able to.
  • the object is to provide an encryption information creation apparatus for creating encryption information including encrypted information obtained by encrypting information to be transmitted, and a member including a public key of one of the members to be distributed in broadcast communication.
  • a member list management device that manages the list, an encryption information decryption device that decrypts the encrypted information, and encryption information transmitted from the encryption information creation device, and the symbol information is received.
  • a member list management device in a broadcast communication system comprising: an information relay device that distributes the encrypted information to one or more cryptographic information decryption devices based on the member list;
  • This can be achieved by a device called a member list management device including a list creation unit for creating a member list including public keys of one or more members, and a public key management unit for acquiring and storing the public key.
  • the information encrypted by the information relay device is decrypted.
  • the system does not have such a mechanism, so it is possible to prevent the contents of the broadcast communication from being leaked or falsified by the administrator of the information relay device, and to allow only members who really need to share the information to share the broadcast contents.
  • the object is to provide a team composed of members who share information with each other by notifying a predetermined request destination of information for identifying and authenticating the instructor who issues a change instruction. And a digital signature of a master having the authority to manage the information, and obtain a team data list prepared according to the authority of the members belonging to the team from the request destination.
  • the list creator confirmation section that checks whether or not a master with authority has created the team data list based on the contents of the metadata list, and the creation of a master with the authority.
  • a list change unit for making a change to the confirmed team data list in accordance with the change instruction; a digital signature of the instructor; and a team data changed by the list change unit. Attach the digital signature to the list is reached by a device that Chi Mudetarisu Bok management apparatus and a digital signature unit to send to the request destination.
  • a master list and a team data list such as a membership list stored in a server or the like are acquired in response to a change instruction from a master having a legitimate authority, and the lists obtain the authority. After confirming that the list is properly created by the master, the list is modified and returned to the request destination. From this, it is possible to detect that an unauthorized person, such as a general member other than the master, a server administrator, or a cracker, has manipulated the team data list.
  • FIG. 1 shows a basic configuration of an information sharing system according to the invention of the first embodiment.
  • FIG. 2 is a block diagram showing a configuration example of the encryption / decryption device according to the invention of the first embodiment.
  • FIG. 3 is a diagram illustrating a configuration example of the decoding unit in FIG.
  • FIG. 4 is a diagram showing various lists stored in the WWW server.
  • FIG. 5 is a diagram for explaining the detailed functions of the DBMS in the WWW server as the information management device according to the first embodiment of the present invention.
  • FIG. 6 is a diagram for explaining a registration operation of a public key ID to a group when a common key is shared by the groups.
  • FIG. 7 is a diagram for a case where a common key is shared by a group, for explaining an example of a common key registration operation.
  • FIG. 8 is a diagram for explaining an operation example in a case where a group shares a common key and data is encrypted.
  • FIG. 9 is a diagram for explaining an operation example in the case where data to be shared is separately identified and data is decoded.
  • FIG. 10 is a diagram for describing an example of a decoding operation.
  • FIG. 11 is a block diagram illustrating the operation principle of the information tampering detection device according to an embodiment of the second embodiment.
  • FIG. 12 is a block diagram showing a configuration of an information tampering detection device according to the same embodiment.
  • FIG. 13 is a flowchart for explaining the operation of the reception content confirmation information confirmation unit 103/3 shown in FIG.
  • FIG. 14 is a flowchart for explaining the operation of the transmission content confirmation information creation unit 104/3 shown in FIG.
  • FIG. 15 is a flowchart for explaining the operation of the reception content confirmation information creation unit 202j3 shown in FIG.
  • FIG. 16 is a flowchart for explaining the operation of the transmission content confirmation information confirmation unit 205 shown in FIG.
  • FIG. 17 is a diagram illustrating the operation principle of a conventional information tampering detection device.
  • FIG. 18 is a diagram for explaining the drawbacks of the conventional information tampering detection device.
  • FIG. 19 is a block diagram showing a configuration of an encryption / decryption device according to an embodiment of the inventions of the 3-1 to 3-3 embodiments.
  • FIG. 20 is a diagram showing one utilization form of the inventions of the third to third embodiments.
  • Fig. 21 is a flowchart for explaining the operation related to the encryption.
  • Fig. 22 is a diagram showing the configuration of the information before encryption and the encrypted information.
  • -Fig. 23 is a diagram related to the decryption.
  • FIG. 24 is a flowchart illustrating the operation when adding information to the encrypted information.
  • FIG. 25 is a diagram showing the configuration of encrypted information before and after information is added to the encrypted information.
  • FIG. 26 is a flowchart illustrating the operation when the sharing member 1 adds the sharing member 1C to the team.
  • FIG. 27 is a diagram showing the configuration of the encryption information before and after adding the shared member 1C to the team.
  • Figure 28 is a flowchart describing the operation when removing a shared member from a team.
  • FIG. 29 is a diagram showing the configuration of the encrypted information before and after deleting the shared member ⁇ from the team.
  • FIG. 30 is a diagram illustrating information stored in the information storage device according to the 3-1st embodiment.
  • FIG. 31 shows the information storage device when information is added in the third-second embodiment.
  • FIG. 4 is a diagram showing information stored in the storage device.
  • FIG. 32 is a diagram showing a display example of a schedule after decoding in the third to third embodiments.
  • FIG. 33 is a flowchart illustrating the operation of encryption in the conventional encryption / digital signature scheme.
  • FIG. 34 is a flowchart illustrating a decryption operation in the conventional encryption / digital signature scheme.
  • FIG. 35 is a diagram showing the configuration of information before encryption and the encrypted information according to the encryption method disclosed in Japanese Patent Application Laid-Open No. 8-15664.
  • FIG. 36 is a diagram showing a configuration of information before encryption and encrypted information by the encryption method disclosed in Japanese Patent Application Laid-Open No. 9-71388.
  • FIG. 37 is a block diagram showing a configuration of a system having a team data list management device and a team data overnight list storage device according to the fourth embodiment.
  • FIGS. 38A, 38B, 38C, and 38D are explanatory diagrams showing the structure of the team data list stored in the server on which the team data list storage device is installed in the forty-first embodiment.
  • FIG. 39 is an explanatory diagram showing an example of a team hierarchy in the fourth embodiment.
  • FIG. 40 is an explanatory diagram in which specific values of the team list are written for each team in the team hierarchy shown in FIG.
  • FIG. 41 is an explanatory diagram showing a processing procedure for creating a sub team in the 4-1 embodiment.
  • (A) means a sub-team creation request by member C (sub-team 103 ⁇ is created under team 101, with team mass X as X), and S 116-S 1
  • the meaning of 5 ⁇ is as follows.
  • Data list management device 3 0 ⁇ is related to team 10 1 ⁇
  • (B) means a management request of the team 103 ⁇ by the member X, and S 16 ⁇ 5 to S 19 (5 means the following, respectively.
  • (C) means the designation of W and V as the sub-team creation authority (sub AU ⁇ ) by member X, and the meaning of S 205 to S 21 ⁇ 5 is as follows: It is as follows.
  • FIG. 42 is an explanatory diagram showing a processing procedure of a server-side authority confirmation function performed at the time of a sub-team creation request in the process of FIG.
  • Figure 43 shows the client-side list that is implemented in the process of Figure 41.
  • FIG. 9 is an explanatory diagram showing a processing procedure related to validity verification.
  • FIG. 44 is an explanatory diagram showing a processing procedure when the server confirms the authority of the team data list newly created on the client side in the process of FIG.
  • FIG. 45 is an explanatory diagram showing a processing procedure for changing the team space of the sub team in the fourth embodiment.
  • FIG. 46 is an explanatory diagram showing a processing procedure for changing (deleting) the authority to create a sub-authority in the fourth embodiment.
  • FIG. 47 is an explanatory diagram showing a processing procedure for deleting a subteam in the 4-1 embodiment.
  • (A) means the deletion of the previously created sub team 103 ⁇ of 101 ⁇ by member C, and the meaning of S 81 ⁇ 5 to S 82 ⁇ is as follows.
  • ( ⁇ ) means a request to delete team 103 ⁇ by the authority of member S
  • the meaning of S83 (5 to S84 ⁇ ) is as follows.
  • a ⁇ ⁇ of 101 ⁇ 5 A has designated as subAU
  • the C has created 103 ⁇ 5 (signing AUD5 for 103 ⁇ 5
  • FIG. 48 is an explanatory diagram showing a procedure of a method called a challenge or challenge response used by the server when confirming the authority of a user at the client side.
  • FIG. 49 is an explanatory diagram showing an example of the team hierarchy in the 4-2 embodiment.
  • FIG. 50 is an explanatory diagram showing an example of the team hierarchy in the fourth to third embodiments.
  • Figure 51 shows the configuration of a conventional system that shares information using an access control list.
  • FIG. 1 A first figure.
  • FIG. 52 is a diagram showing the structure of the broadcast communication system according to the fifth embodiment of the present invention.
  • Figure 53 shows an example of a general member list.
  • Figure 54 is an example of a member list composed of multiple lists.
  • FIG. 55 is a diagram showing an embodiment of the member list management device of the present invention.
  • FIG. 56 is an operation flowchart of the list creation unit.
  • FIG. 57 is a diagram showing an embodiment of the cryptographic information creation device of the invention of the fifth embodiment.
  • FIG. 58 is a diagram showing an encryption / decryption process in the broadcast communication system according to the fifth embodiment of the present invention.
  • FIG. 59 is a diagram for explaining a mechanism of multiple-packet transmission and multiple-packet reception in the broadcast communication system according to the fifth embodiment of the present invention.
  • FIG. 60 is a diagram illustrating an embodiment of an encryption information decryption device according to the fifth embodiment of the present invention.
  • FIG. 61 is a diagram showing an embodiment of the information relay device of the invention of the fifth embodiment.
  • FIG. 62 is an example in which the broadcast communication system of the fifth embodiment is applied as a securities news distribution system.
  • FIG. 63 shows an embodiment of the broadcast communication system of the present invention using a mailing list server.
  • FIG. 64 is a diagram illustrating the structure of a conventional broadcast communication system.
  • FIG. 65 is a diagram for explaining the mechanism of the broadcast communication system disclosed in Japanese Patent Laid-Open No. 7-245605.
  • FIG. 66 is a block diagram showing a configuration of a system having a team data list management device and a team data list storage device according to an embodiment of the sixth embodiment.
  • FIG. 67 is the first diagram for explaining the technology underlying the invention of the sixth embodiment, and shows a configuration in which a member list management function and a storage function are divided between a client and a server. It is a block diagram.
  • FIG. 68 is a second diagram for explaining the technology underlying the invention of the sixth embodiment, and is a process when a member included in a member list on a server is changed from a client side.
  • FIG. 9 is an explanatory diagram showing a procedure. 1 2
  • FIG. 69 is an explanatory diagram showing a procedure of a technique called a shake hand or a challenge response used by the server when confirming the authority of the user at the client side.
  • FIG. 70 is an explanatory diagram showing a processing procedure relating to a member change in a case where members are managed by a plurality of administrators in the embodiment.
  • FIG. 71 is a flowchart showing a processing procedure of a list creator confirmation performed on the client side in the embodiment.
  • FIG. 72 is an explanatory diagram showing a processing procedure relating to a change of a sub cell in a case where members are managed by a plurality of administrators in the embodiment.
  • FIG. 73 is an explanatory diagram showing a processing procedure for changing a team cell when the members are managed by a plurality of managers in the embodiment.
  • FIG. 74 is a flowchart showing a processing procedure of authority confirmation performed on the server side when the team cell shown in FIG. 73 is changed in the embodiment.
  • New team list is the old team list
  • FIG. 75 shows a comparison and verification at each step in the same embodiment when performing the authority confirmation shown in Fig. 74 in the same embodiment.
  • FIG. 7 is an explanatory diagram showing a state of a team master list and a member list to be executed.
  • FIG. 76 is a block diagram showing a configuration of a conventional system for sharing information using an access control list.
  • FIG. 77 is an explanatory diagram showing a processing procedure performed between client servers in order to share information only with members belonging to a specific group.
  • the invention of the first embodiment relates to an information sharing system for preventing information from being viewed or falsified, an information processing method thereof, and a recording medium for the purpose of information sharing among a plurality of users. is there.
  • the technology described below is conventionally known.
  • various types of digital information have been used on computer networks.
  • the present invention has been made in view of the above circumstances, and has as its object to inspect and alter the content of information by an administrator of a database, a server, a file system, or the like that stores encrypted information. It is an object of the present invention to provide an information sharing system, an information processing method thereof, and a recording medium that can prevent the occurrence of a problem.
  • a shared key cryptosystem and a public key cryptosystem are used in combination in order to keep information shared by a plurality of users secret.
  • the input information is encrypted using a common key in a shared key cryptosystem.
  • an information sharing system on a network is realized.
  • At least an information storage device that can be accessed by a plurality of members has at least a digital signature of the team master, a list of members including members and public key information, and a common key including encryption key information. List and encrypted data are stored. 15
  • a member belonging to a group is additionally registered, a member list is obtained from the information storage device, and it is determined whether the digital signature of the team master of the obtained member list matches the designated digital signature. You. Only when there is a match, a new member list including at least the digital signature of the team master and member-public key information is created, and the created member list is transferred to the information storage device and stored. .
  • a member list is obtained from the information storage device, and the digital signature of the team master of the obtained member list matches the designated digital signature. It is determined whether or not to do so.
  • the common key to be registered is encrypted using the specified public key, and the encrypted common key is transferred to the information storage device and stored.
  • data is encrypted using the common key, at least encryption key information is obtained from the common key list of the information storage device, and the common key is decrypted from the encryption key information.
  • the input information is encrypted with the decrypted common key based on the common key encryption method to generate encrypted data, and the encrypted data is transferred to the information storage device and stored.
  • decrypting data desired encryption key information and encryption data are obtained from the information storage device, and the common key is decrypted from the encryption key information.
  • the member list is changed according to the request by the group management means.
  • the common key management unit When there is a request for registration of a common key, the common key management unit registers the requested common key including its encryption key information. When there is a request to acquire a common key, the common key management unit selects the optimal common key for information sharing in a specific group and transfers it to the request destination.
  • the encrypted data is stored by the encrypted data management unit together with the common key information used for encrypting the data.
  • the encrypted data management unit transfers the stored encrypted data and the common key information to the request destination.
  • FIG. 1 is a basic configuration diagram of an information sharing system according to the present invention
  • FIG. 2 is a block diagram illustrating a configuration example of an encryption / decryption device according to the present invention.
  • Information sharing system according to the present embodiment (first embodiment), as shown in FIG. 1, the first terminal equipment 1 and the encryption decryption shown in FIG. 2 apparatus 1 0 alpha is incorporated WWW server as an information storage device for storing a list of members generated by the encryption / decryption device 10 ⁇ , a common key list, encrypted data, etc. ⁇ is connected by a network (for example, the Internet) 4 ⁇ .
  • a network for example, the Internet
  • the list management unit is composed of the digital signature confirmation unit 17 ⁇ , the public key management unit 18 ⁇ , and the digital signature addition unit 19a as main elements.
  • the encryption unit 11 ⁇ uses a common key dk for encrypting information or a common key ck ⁇ read from the WWW server 3 ⁇ , and uses, for example, a shared key code method (for example, DES) to input the input information ⁇ .
  • the encrypted data M′ ⁇ is generated by encrypting the data, and the generated encrypted data ⁇ ′ ⁇ is output to the transfer unit 16 ⁇ .
  • the encryption unit 11 ⁇ is used when a group shares a common key, and when encrypting data, a request for a member list of a specific group, specifically, a group ID or a user public key ID is used.
  • a request for a member list including the request is made to the WWW server 3 ⁇ . This request is transferred via the transfer unit 16a.
  • the common key generation unit 12 is composed of, for example, a random number generation circuit, etc., generates a common key dk for encrypting information, and outputs it to the encryption unit 11 ⁇ and the encryption key generation unit 14 ⁇ . I do.
  • the common key dka is generated, for example, as 64 bit data.
  • the storage unit 13 is composed of, for example, a hard disk, in which unique public keys PK 1 ⁇ , ⁇ ⁇ 2 ⁇ ,..., ⁇ ⁇ ⁇ ⁇ of each of a plurality of n users sharing this system are recorded in advance. It is accessed by the encryption key generator 14 ⁇ and the public key manager 18.
  • the encryption key generation unit 14 uses the public key dk ⁇ (or the common key ck ⁇ ) used for encryption by using the public key of the user recorded in the storage unit 13 ′′. 18. For example, one or a plurality of encryption keys ⁇ ⁇ , ⁇ , ⁇ ⁇ 2 ⁇ ,..., ⁇ ⁇ ⁇ are encrypted based on a public key cryptosystem (for example, RSA), and the generated encryption key is generated. EK 1, ⁇ ⁇ 2 ⁇ , ..., ⁇ ⁇ are output to the transfer unit 16 ⁇ . Also, the encryption key generation unit 14 ⁇ transmits a member list request of a specific group to a WWW server when a member belonging to a specific group wants to share information and registers a common key used by the member.
  • a public key cryptosystem for example, RSA
  • the transfer of this request is performed via the transfer unit 16 ⁇ .
  • the additional information generation unit 15 generates, for example, a message digest kmd of the common key dk ⁇ using a hash function or the like, and outputs it to the transfer unit 16 ⁇ as the additional information ajf.
  • any one of ID, user password, certificate, e-mail address, public key, and order information for identifying the encryption key that can be decrypted with the user's private key may be information combining multiple items.
  • the transfer unit 1 6 alpha, input information Micromax Hino encrypted encryption key ⁇ 1 ⁇ 1 or multiple generated in association with, ⁇ 2 ⁇ , ..., ⁇ ⁇ ⁇ ⁇ , encrypted data Micromax 'shed, And the additional information ajf ⁇ is transferred to the WWW server 3 ⁇ as an information storage device via the network 4 ⁇ .
  • the transfer process is not performed when registering the common key.
  • the digital signature confirmation unit 17 receives the public key member list GL ⁇ belonging to a specific group stored on the WWW server 3 via the network 4 ⁇ and obtains the digital signature of the team master. Confirm and, if the confirmation is positive, add the public key of the user joining the new group.
  • 19 public key PK of the is output from the storage unit 1 3 alpha to the public key management unit 1 8 alpha, to remove the appropriate members one to members listed in Menpari scan Bok received when there is a member one you defections
  • the public key ⁇ corresponding to the public key ID list is output from the storage unit 13 ⁇ to the encryption key generation unit 14 ⁇ .
  • the public key management unit 18 ⁇ receives the designated public key ⁇ ⁇ output from the storage unit 13 ⁇ when adding the public key of a user who newly joins the group, and receives a new member list. Is created, the public key number ( ⁇ ⁇ ) and the member's public key are set in the list, and a group ID is added to the new member list and output to the digital signature adding section 19 ⁇ . Further, for example, when a member list request of a specific group is generated, the request is made to the WWW server 3 ⁇ .
  • the digital signature adding unit 19 adds a digital signature of the team master to the new list created by the public key management unit 18 ⁇ , and sends it to the WWW server 3 as an information storage device via the network 4 ⁇ . Transfer to ⁇ to register.
  • the decryption unit 20 ⁇ When a specific group shares a common key, the decryption unit 20 ⁇ generates a desired common key number ( ⁇ ⁇ ) from the common key list CKL ⁇ registered in the WWW server 3a. ), Obtains the encryption key, decrypts the encryption key with the user's secret key ⁇ V k using public key cryptography (for example, RS ⁇ ), obtains the common key, and sends it to Output.
  • public key cryptography for example, RS ⁇
  • the data ID and public key number (No) are transferred to the WWW server 3 and encrypted. 20 Obtain the key and data, decrypt the common key using public key cryptography, and decrypt the data using common key cryptography.
  • the decryption unit 2 O c is composed of an encryption key decryption unit 21 and an information decryption unit 22 ⁇ .
  • the decryption unit 20 ⁇ identifies, for example, algorithms of a shared key encryption method and a public key encryption method stored in the WWW server 3a in addition to a plurality of encryption keys, additional information, and encrypted data.
  • the algorithm identification information desrsa for example, encrypted with DES and RSA
  • other information info for example, the initialization random number used for DES
  • the r server 3 ⁇ has a database management system (DBMS) 31 ⁇ and an authority confirmation unit 32 ⁇ having an authority confirmation function.
  • DBMS database management system
  • list CKL alpha common only be sampled GCKL alpha of group encryption Detari be sampled EDL alpha, and de one data common key list DCKL alpha recorded in a predetermined storage unit stores.
  • the DBMS 31a has three pieces of information, a member list management section 311 ⁇ , a common key management section 312, and an encrypted data management section 313. It has a management storage function. These functions use the authority confirmation function to confirm whether each change, registration, or data storage request satisfies the authority. 21
  • the member list management unit 311 ⁇ receives the member list change request from the client side, accesses the member list GL ⁇ , responds to the member list change request, and is returned. Change the member list GL ⁇ according to the requirements of the team master. Also, the member list management unit 311 has a function to add / delete the entire group.
  • the common key management unit 3 1 2 alpha, when the common key register, access the common key list GCKL a common key list CKL a and groups, to register the common keys.
  • the common key management unit 312 responds to the request for a common key that is optimal for information sharing in a specific group at that time. ), Select the latest common key) and transfer it to the client. If, for example, an encryption key and group ID information related to the common key to be registered are received, they are sorted and stored in each list. At that time, a common key ID is generated.
  • the member list management unit 311a checks the authority and refers to the group ID to obtain the public key numbers (No) and the public keys of the members belonging to the specific group. get.
  • the common key management unit 3 1 2 refers to the group ID from the group common key list GCKLa and searches for all common key numbers (No) used in the specific group.
  • the common key list CKL ⁇ than, the common key number ( ⁇ 22. Obtain all the encryption keys that match o) and the public key number (No) of the team master and transfer them to the client.
  • the member list management unit 311 and the common key management unit 312 2 ⁇ send the returned encryption key, member list, and public key as a result of processing such as change and encryption on the client side.
  • the member list GL ⁇ , common key list CKL ⁇ , and group common key list GCKL are changed.
  • the member list management unit 311 ⁇ and the common key management unit 312 ⁇ cooperate to perform the following processing.
  • the member list management unit 311 ⁇ updates the member list.
  • the new member list is compared with the member list before the update, the public key number (No) of the deleted member is calculated, the group ID and the public key number of the deleted member (No) are determined. No) is passed to the common key management unit 3 1 2 ⁇ .
  • the common key management unit 3 1 2 ⁇ searches for the common key number (No) used in the specific group by referring to the group ID from the group common key list GCKL. G. From CKL ⁇ , delete all encryption keys that match each common key number (No) and the deleted member's public key number (No). In DBMS 31 ⁇ , if the addition and deletion of one member are performed at the same time, 23. In this case, the above methods are combined and executed.
  • the encrypted data storage unit 3 1 3 ⁇ cooperates with the common key management unit 3 1 2 ⁇ , and the group common key list GCKL ⁇ , common key list CKL a, data common key list DCKL a Then, the encrypted data list EDLa is accessed, the member list is transmitted and the encrypted data is received according to the client's request, and the data ID is generated. When a decryption request is received, it refers to the data ID and public key number (No) and returns encrypted data and an encryption key by referring to three lists. Next, the operation of the above configuration will be described.
  • a client requests a member list of a specific group to the WWW server 3a, for example, from the public key management unit 18a ( S61a).
  • a list of public key IDs belonging to a specific group is encrypted from the WWW server 3a via the network 4 on the client side. 24. Transferred to the decryption device 10 (S6 2 c c
  • the member list which is the public key list, is input to the digital signature confirmation unit 17, where the digital signature of the team master is confirmed (S 63 a). ).
  • the public key PK is output from the storage unit 13a to the public key management unit 18a, and the member who withdraws from the group.
  • the public key of the member is deleted from the members listed in the received member list (S64a).
  • the public key management unit 18a creates a new member list (S65h), a public key number (No), and a member number.
  • the public key and group ID are set in the list and output to the digital signature adding section 19a.
  • the digital signature of the team master is added to the new member list by the public key managing section 18a (S6 ⁇ ⁇ ).
  • a request for updating the member list is made from the digital signature adding section 19a to the WWW server 3a, and the member list management section 311 1 in the WWW server 3a requests the member list.
  • the update of the store GLa is performed (S67a) ⁇ If the digital signature verification is negative in step S63a, the team master updates or deletes the member list, etc. And so on, the processing after step S64a is not performed. twenty five -
  • the authority such as access is confirmed, and a request for a list of members of a specific group is sent from the client side (terminal side) to the WWW server 3 ⁇ , for example, from the encryption key generation section 14 ⁇ . divided by (S 7 1 ⁇ ).
  • a public key ID list belonging to a specific group is transferred from the WWW server 3 ⁇ to the client-side encryption / decryption device 10 ⁇ via the network 4 ⁇ (S7). 2 ct).
  • the member list which is the public key list
  • the digital signature confirmation unit 17 ⁇ where the digital signature of the team master is confirmed (S 7). 3a). If the confirmation is affirmative, the public key PK corresponding to the public key ID list is output from the storage unit 13 to the encryption key generation unit 14.
  • the common key S key 1 ⁇ generated by the common key generation unit 12 ⁇ is encrypted using a given public key, for example, based on a public key cryptosystem.
  • a given public key for example, based on a public key cryptosystem.
  • one or more encryption keys ⁇ ⁇ ⁇ are generated by adding a common key list data including a public key number and a member-one public key, and output to the transfer unit 16 ⁇ . (S74).
  • the common key list data including the encryption key to which the common key list data including the public key number and the member-one public key is added by the transfer unit 16 is transmitted to the WWW server 3 via the network 4 ⁇ .
  • shared key management unit 3 1 2 ⁇ 26 to be stored in the specified place as shown in Fig. 7 (S75a) c
  • the information transferred from the transfer site 16 may include the additional information generated by the additional information generation unit 15 in some cases. If the digital signature check is negative in step S73, the team master is deemed to have no authority to register the common key, and the processing from step S74 ⁇ is performed. Absent. Next, a case where a group shares a common key and data is encrypted will be described with reference to FIG.
  • the authority such as access is confirmed, and the client (terminal) requests the member list of a specific group, specifically the group ID and user public key ID (for example, the number “IC: FF”).
  • the request is made to the WWW server 3 ⁇ from, for example, the encryption unit 11 ⁇ (S81).
  • a common key belonging to a specific group for example, “1 2 2”
  • an encryption key (“ ⁇ Xc ⁇ ”) are transmitted from the WWW server 3 via the network 4 ⁇ . Is transferred to the client-side encryption / decryption device 10 ⁇ (S82 ⁇ ).
  • the decryption unit 20 ⁇ acquires the common key number (122) and the encryption key (zxcv), and uses the public key cryptosystem to secure the user's secret.
  • the encryption key is decrypted with the key ⁇ V k ⁇ to obtain the common key S key 2 ⁇ , which is output to the encryption unit 11 ⁇ (S83a, S84a).
  • Input information M Higa shared key encryption method (e.g., DES) is encrypted using a common key S key 2 alpha on the basis of the common key number (1 2 2) encrypted data is added
  • Micromax 'alpha (For example, “; ijjjjjjjjjjjjJ) is generated and output to the transfer unit 16 (S85 ⁇ ).
  • the encrypted data M ′ a (for example, rjjjjjjjjjjjjjjj) to which the common key number (122) has been added by the transfer unit 16 ⁇ is transferred to the WWW server 3 ⁇ via the network 4 ⁇ , and the encrypted data It is stored in a predetermined place by the management unit 313 ⁇ as shown in Fig. 8 (S86a).
  • the case where the user who wants to share is specified separately and the data is encrypted will be described with reference to FIG.
  • the input information ( "Hello") is input to the encryption unit 1 1 alpha of the encryption device 1 0 alpha.
  • the common key generation unit 12 generates a common key S key 1 a (S 9 1 ⁇ ), and the common key S key 1 ⁇ is used as the encryption unit 12 a and the encryption key generation unit 14. (S 9 2 a, S 9 3 a) 0
  • the encryption unit 11 a encrypts the input information Ma using the common key S key 1 a based on the shared key code system DES.
  • the encrypted data M ′ a (for example, “: jjjjjjjjjjjjjj”) to which the common key number (for example, “1 2 4”) is added is generated and output to the transfer unit 16a.
  • the public key PKa based on the public key cryptosystem (for example, RSA) of the users A, B, and C is read from the storage unit 13a.
  • the encryption key generation unit 14 uses these public keys to encrypt the common key S key 1 a based on the public key code method. 28.
  • the encryption key (olkj, ⁇ iwi, Xknm) is obtained, and the public key number (“1 1:
  • the encrypted data ⁇ ′ ⁇ (for example, “; jjjjjjjjjjjjjjjj”) to which the common key number (for example, “1 2 4”) is added by the transfer unit 16 ⁇ , and the encryption key (o 1 kj, O iwi, X knm) and data including public key numbers (“11: AA”, “1C: FF”, “E5: 4B”) are transmitted to the WWW server via network 4 ⁇ .
  • the decoding unit 2 0 alpha from the data ID for example, "4 4 4 4"
  • a public key ID is transmitted to the WWW server 3 a (S 1 0 1 ⁇ ).
  • the WWW server 3 ⁇ uses the received data ID and a common key number (eg, “1 2 2 J”) to generate the encrypted data (eg, “; jjjjjjjjjjjj” and the corresponding encryption key (z X c V ) Is read out from a predetermined storage location by the encrypted data management unit 313 ⁇ , and transferred to the client via the network 4ct (S102h).
  • a common key using the private key corresponding to the public key ID is decoded as S key 2 ⁇ (S 1 0 3 flight).
  • the common key S key 2 alpha using, de on the basis of the common key encryption method - data is decoded as "Hello" (S 1 0 4 a).
  • each list is read so that the new member can read the information shared by the group before the registration. 29, and when removing a member from a particular group, modifying each list to prevent the deleted member from reading information shared by the group since the removal.
  • the operation of the WWW server 3 ⁇ will be described. First, a case will be described in which, when a new member is registered in a specific group, each list is changed so that the new member can read information shared by the group before the registration.
  • the authority is confirmed by the member list management unit 311a, and the member ID belonging to the specific group (for example, team B) is referred to by referring to the group ID.
  • Public key number (No) and public key are obtained from member list GLa.
  • the group ID is referred to from the group common key list GCK La, and the common key number (for example, 5 2 , 1 1 1 and 1 2 3) are all searched.
  • each common key number for example, 52, 111, 123 and the public key number of the team master (for example, 1) are obtained from the common key list CKLa. 1: All encryption keys that match AA) (eg, qwer, peha, gobp) are obtained and transferred to the team master's client.
  • AA eg, qwer, peha, gobp
  • a common key obtained by decrypting the member list and all the encryption keys for example, S keylOO, S key 105, S key 80 ⁇
  • those common keys are newly registered.
  • the member's public key eg, xhen, mxco, henc
  • these encryption keys a list of members, a public key number (for example, L2: CA) and a common key ID (for example, 52, 111, 123) are transmitted to the WWW server 3 ⁇ .
  • the member list management unit 311 ⁇ and the common key management unit 312 ⁇ the returned encryption key and member list as a result of processing such as change and encryption on the client side, and disclosure Receiving the key number (No) and the common key ID, the member list GL, common key list CKL ⁇ , and group common key list GCKL a are changed.
  • the newly added member can obtain the past shared information because the public key is included in the common key list.
  • the member list management unit 311 of the WWW server 3 ⁇ updates the member list.
  • the new member list is compared with the member list before the update, and the public key number (No) of the deleted member is determined.
  • the group ID and the public key number (No) of the deleted member are passed to the common key management unit 312 ⁇ .
  • the common key management unit 312 2 ⁇ refers to the group ID from the group common key list G CKLa and uses the common key number (for example, 3 8 , 444, 1 3 3) are all searched. 31 ⁇ Next, in the common key management unit 312, from the common key list CKLa, each common key number (for example, 38, 44, 13) and the public key number of the deleted member (For example, LL: BB) All the encryption keys that match are deleted. In addition, in the WWW server 3, more specifically, in the DBMS 31, when the addition and deletion of members are performed at the same time, the above methods are combined and executed.
  • At least a plurality of media can be accessed, at least a digital signature of the team master, a member list including member public key information, and a common key including encryption key information.
  • List and encrypted data are stored on three WWW servers, a storage unit that stores the public key of at least one member who can see the information, and a storage unit that encrypts the information.
  • An encryption unit 11 ⁇ that encrypts input information based on the common key encryption method using a common key to generate encrypted data and a common key used for encryption are stored in a storage unit and designated.
  • An encryption key generation unit 14 ⁇ that encrypts with the obtained public key and generates an encryption key
  • a transfer unit 16 ⁇ that transfers and stores multiple encryption keys and encrypted data to the WWW server 3 ⁇ .
  • Members from WWW server 3 ⁇ To determine whether the digital signature of the relevant team member's team master matches the specified digital signature, and if so, add the member's public key or publish the member to leave The key is deleted from the above storage unit, and in the case of additional registration or deletion, a new member list including at least the team master's digital signature and member's public key information is created! :
  • the list management units 17 ⁇ , 18 and 19 ⁇ to be transferred to the above information storage device and stored, and the desired encryption key information and encrypted data are obtained from the WWW server 3 ⁇ , and this encryption is performed.
  • the WWW server 3 ⁇ as the information storage device accesses the member list GL and responds to the member change request.
  • the member list management unit 311 1 ⁇ that can change the member list GL ⁇ in response to the request from the returned team master, and the shared key request from the client.
  • the common key management unit 312 ⁇ that selects the optimal common key for sharing and transfers it to the client, the group's common key list GCKL a, the common key list CKL, the data common key list DCKL, and encryption Aaccessed the encrypted data list EDLa, sent a member list and received encrypted data according to the client's request, generated a data ID, and received a decryption request.
  • an encrypted data storage unit 313 is provided that refers to the data ID and public key number (No) and returns encrypted data and the encryption key by referring to the three lists.
  • there is no risk that the data of users who are shared using databases that store encrypted data or information storage devices such as servers and file systems can be seen or tampered with.
  • the programs for changing, registering, storing, etc., are stored in a storage medium readable by the first and second terminal devices (computers) 1 ⁇ and 2 ⁇ , for example, a floppy disk provided in the encryption device 10 ⁇ or a server. It is recorded on a peak disk, hard disk, optical disk, semiconductor storage device, etc., and is read and executed by the terminal device.
  • a transmission / reception notifying unit may be further provided for sending a transmission notification notifying the receiving side of the fact and a receiving notification notifying the transmitting side that the receiving side has reliably received the information.
  • the receiver can use the transmission / reception notification unit to reliably send the information to the sender or the information communication device or information storage device to which the information was relayed at the time of reception (after tampering confirmation and decryption). It can send a reception notification to confirm that it has been received.
  • the information included in these notifications includes the content (or part of) the information transferred from the sender, an overview, information identifying the sender, information identifying the recipient, information acquisition and storage location. (e.g. URL address, directory, etc.), the c Specifically, etc. information acquisition date, the information storage device, encrypting the data management unit of FIG. 5 (3 1 3 alpha) 34. Add the function of the transmission / reception notification unit.
  • the encryption / decryption device creates a transmission notification or a reception notification by using information included in the above-described notification used for encryption or obtained at the time of decryption, and performs communication.
  • communication means an external communication function such as a mail protocol connected to the terminal or an HTTP protocol provided in a browser can be used instead.
  • the sender and receiver can confirm that the communication has been performed securely in order to increase the security of communication. This is because it is desirable.
  • the sender uses the transmission / reception notifier to notify the receiver or the information relay device or the information storage device that the information was relayed at the time of transmission (at the time of encryption) to the effect that the information was certainly transmitted.
  • a transmission notification can be sent.
  • the security can be further improved by transferring the notification using another protocol such as SMTP, and confirming the existence of the communication on both the sending and receiving sides.
  • SMTP another protocol
  • a shared key can be shared by a group, and a database for storing encrypted data, a file system administrator, and a file system administrator can receive information. There is no possibility of seeing the contents.
  • the invention of the second embodiment relates to, for example, an information tampering detection device used for detecting tampering of information in network transmission and a computer-readable recording medium recording a tampering detection program.
  • information tampering detection technology a technology for detecting information tampering (hereinafter referred to as information tampering detection technology)
  • a digital signature technology has been put to practical use by an information tampering detection device.
  • Examples of common digital signature technologies include a Digital Signature Algorithm or a combination of a public key cryptosystem (eg, RSA) and a hash function (eg, MD 2).
  • FIG. 17 is a diagram illustrating the operation principle of the above-described conventional information tampering detection device.
  • the information tampering detection device shown in Fig. 17 is a transmitting terminal installed on the sender side.
  • step SA1 the transmitting terminal 1] 3 encrypts the plaintext 2 to be transmitted to the receiving terminal 6. Specifically, the transmitting terminal l j3 creates a ciphertext 3 from the plaintext 2 ⁇ using the public key of the receiver (receiving terminal 6] 3). Then, in step S A 2
  • the transmitting terminal 1] 3 compresses the plaintext 23 using a hash function to create an MD j3 (message digest) 4a
  • a hash function is a function that is computationally infeasible to find any two different inputs that have the same output value, and as a part of mechanisms such as digital signatures From long messages to relatively short, for use 36.
  • step S A 3 3
  • the authenticator 5 is a digital signature given to the plaintext 2/3 that is the basis of the ciphertext 3] 3.
  • the digital signature is obtained through a first process of creating a message digest and a second process of encrypting the message digest with a secret key.
  • the digital signature may be obtained through a process of encrypting information that has not been message digested or a combination of the message digest and the information with a private key in addition to the above process. Including. Then, the transmitting terminal 1 transmits the ciphertext 3/3 and the authenticator 5j3 to the receiving terminal 6/3 via the network. Thus, after receiving the ciphertext 3/3 and the authenticator 5, the receiving terminal 613 first uses the secret key of the receiver (receiving terminal 63) in step SA4j3 to encrypt the ciphertext 3; 3. Is decrypted to create plaintext 20.
  • step S A50 receiving terminal 6 creates MD ⁇ 4 b ⁇ by compressing the decrypted plain text 2 ⁇ using a dash function.
  • step SA 6 j3 the receiving terminal 63 decrypts the received authenticator 5 by using the public key of the sender (transmitting terminal 1 ⁇ ) to generate ⁇ D ⁇ 4c ⁇ . I do.
  • step SA7 the receiving terminal 6 ⁇ receives MD j3 4 b ⁇ 3 and MD 37.
  • the conventional information tampering detection device does not have the right to decrypt the received ciphertext 3 ⁇ as shown in Fig. 18; in other words, the receiving terminal 6 ⁇ that does not have the receiver's private key does not
  • the plaintext 2 ⁇ 3 and, consequently, the MD ⁇ 4b ⁇ cannot be created
  • the transfer information cannot be verified for tampering. Therefore, in the conventional information tampering detection device, when the receiving terminal 6] 3 shown in FIG. 18 transfers the transfer information to another terminal (not shown), the terminal, for example, encrypts the ciphertext 3/3. Even if they have the right to do so, they cannot detect when and where tampering has taken place.
  • the transmitting terminal 1/3 that transfers the transfer information first transfers a digital signature that is not the authenticator 53 (digital signature) created from the original plaintext 2] 3. Even in this case, the terminal cannot detect tampering.
  • a conventional information tampering detection device when tampering is performed on important transfer information, it is important to specify the terminal (location) and time at which the tampering was performed. 38. They cannot detect or identify them.
  • the present invention has been made under such a background. An information tampering detection device and a tampering detection program which can detect tampering of information even in a terminal which does not have a right to decrypt received information are provided.
  • FIG. 11 is a diagram for explaining the operation principle of the information tampering detection device according to one embodiment (second embodiment) of the present invention.
  • the information tampering detection device shown in this figure is composed of a terminal 100 installed on the sender side and a terminal 2 connected to the terminal 100] 3 via a network ⁇ ⁇ such as the Internet. 0 0 ⁇ .
  • step SB 1) terminal 100 (3 compresses transfer information 1 1] 3 using a hash function, and transfers information MD / 3 (message digest) 1 2 a 3
  • the transfer information MD / 3 1 2 a 3 is used for verifying whether or not the transfer contents of the sender and the reception contents of the receiver are different, as will be described later.
  • 3 transmits (transfers) the transfer information 11 ⁇ to the terminal 200 0
  • step SB 3 i3 the terminal 200 j3 encrypts the transfer information MD 1 2 b) 3 using the secret key of the receiver (terminal 200 ⁇ ), and ] 3 is generated.
  • the received content confirmation information 1 3] 3 is obtained by digitally signing the transfer information M ⁇ ⁇ 12 b ⁇ by the receiver (terminal 200/3). 0 0] 3) is information proving that the transfer contents (transfer information 11 ⁇ ) have been received.
  • the digital signature has been made through two processes: message digesting and encryption.
  • the digital signature includes a case in which, in addition to the above process, information that is not converted to a message digest, or a combination of the message digest and the information is encrypted with a secret key.
  • a digital signature is a piece of information, whether or not compressed, encrypted with a private key.
  • the terminal 200) transmits the received content confirmation information 13 iS to the terminal 100 3 via the network N ⁇ .
  • the terminal 100) 3 confirms the received content with the public key of the recipient (terminal 200) 3 in step SB 4/3
  • the information 13 is decrypted to create the transfer information MD ⁇ 12c ⁇ .
  • step S ⁇ 5 in the case of 3, terminal 100) 3 compares transfer information MD] 3 1 2 c] 3 with transfer information MD ⁇ 1 2 a ⁇ to determine whether tampering has been performed. Verify whether or not.
  • the terminal 100/3 receives the verification result as unaltered. If the transfer information MD ⁇ 1 2a ⁇ is different from the transfer information MD012c / 3, 40 The result is tampering.
  • the terminal 1 0 0] 3 encrypts the received content confirmation information 1 3] 3 using the secret key of the sender (terminal 1 0
  • the transmission content confirmation information 14 J3 is obtained by digitally signing the reception content confirmation information 13 by the sender (terminal 100] 3), and the sender (terminal 100 0) 3 ), Information for certifying that the receiver (terminal 200 j3) has transmitted the received transfer contents (transfer information 1 1] 3).
  • the transmission content confirmation information 14/3 is information for certifying that the receiver (terminal 200 ⁇ ) may retain the transfer content (transfer information 11i3).
  • FIG. 12 is a block diagram showing a specific configuration of the information tampering detection device according to one embodiment of the present invention. In this figure, parts corresponding to the respective parts in FIG. 11 are denoted by the same reference numerals. In the terminal 100/3 shown in FIG.
  • 101/3 is an information transmitting unit that transmits the transfer information 11J3 to the terminal 200 via the network N
  • 102 3 is an information receiving unit that receives the received content confirmation information 13/3 (see FIG. 11) transmitted from the terminal 200j3 via the network N3.
  • [10 3] 3 is a reception content confirmation information confirmation unit that executes the processing of steps SB l j3, SB 40 and SB 53 shown in FIG. / 3, sender, communication, and receiver information acquisition unit 103b and digital signature confirmation unit 103CJ3 .
  • the message digest creation section 103a) 3 executes the processing of the SB1 ⁇ in FIG. 41 Create transfer information MD] 3 1 2a / 3 by compressing with a hash function.
  • the sender / communication / recipient information acquisition unit 103 b) 3 acquires the sender information, communication information, and recipient information from the transfer information 1 1] 3 and the received content confirmation information 1 3; 3.
  • the sender information is information on the sender (terminal 100), and includes “sender name”, “ID”, “public key ID”, “mail address”, and a highly reliable third party.
  • the communication information is information on communication between the terminal 100
  • Recipient information is information about the recipient (terminal 2000) 3, and includes “recipient name”, “ID”, “public key ID”, “mail address”, and highly reliable third party. This is information such as an “electronic certificate” issued by the institution.
  • the digital signature confirming unit 103 c] 3 shown in FIG. 12 confirms whether the digital signature of the received content confirmation information 13 ⁇ (see FIG. 11) is from the recipient (terminal 200] 3).
  • 104/3 is a transmission content confirmation information creation unit that executes processing such as step S ⁇ 63 shown in FIG. 11, and a message digest creation unit 104 a) 3, sender, communication, receiver It has an information acquisition unit 104b] 3 and a message digest creation unit 104a] 3.
  • 3 creates transmission content confirmation information 14 ⁇ based on the reception content confirmation information 13 ⁇ .
  • the message digest creation unit 104a creates a message digest from the reception content confirmation information 13/3.
  • Sender, communication, and receiver information acquisition unit 103b] In the same manner as [3], acquire sender information, communication information, and receiver information from reception content confirmation information 13/3.
  • the digital signature adding unit 104c3 encrypts the received content confirmation information 13
  • 105/3 is an information transmitting unit that transmits the transmission content confirmation information 14 ⁇ to the terminal 200 via the network [3].
  • 201 i3 is an information receiving unit that receives transfer information 1 1] 3 transmitted from terminal 100
  • Reference numeral 202 denotes a reception content confirmation information creation unit that executes the processing of steps SB 2/3 and SB 3 jS shown in FIG. 11, and a message digest creation unit 202 a
  • the reception content confirmation information creation unit 202 ⁇ creates reception content confirmation information 1 3] 3 based on the transfer information 1 1) 3.
  • the message digest creating section 202a] 3 compresses the transfer information 11 ⁇ with a hash function to obtain the transfer information MD ⁇ 1 2b ⁇ (See Figure 11).
  • Sender ⁇ Communication-Recipient information acquisition unit 2 0 2 b 13 is the same as Sender ⁇ Communication ⁇ Recipient information acquisition unit 1 0 3 b / 3 described above.
  • 3 Obtain communication information and recipient information.
  • the digital signature adding unit 202c] 3 encrypts the transfer information MD ⁇ 12b ⁇ (see FIG. 11) using the secret key of the receiver (terminal 200 ⁇ ), thereby obtaining the transfer information MD ⁇ . Add a digital signature to ⁇ 1 2b ⁇ .
  • the transfer information MD / 3 12 b to which the digital signature is added is the received content confirmation information 13 ⁇ . 43
  • reference numeral 205/3 is a transmission content confirmation information confirmation unit for confirming the content of the transmission content confirmation information 14 J3 transmitted from the terminal 100/3 based on the transfer information 113. It has a message digest creation / acquisition unit 205a ⁇ , a sender / communication / receiver information acquisition unit 205b0, and a digital signature confirmation unit 205c3.
  • 3 includes the function of creating the message digest described above and the reception content confirmation information creation section 202 23 It has a function of acquiring the transfer information MD ⁇ 1 2b ⁇ (see FIG. 11) already created by the message digest creation unit 202 aj3 of FIG.
  • 3 does not create a message digest.
  • the sender ⁇ communication ⁇ receiver information acquisition unit 205 b / 3 is the same as the sender ⁇ communication ⁇ receiver information acquisition unit 103 b
  • the digital signature confirmation unit 205c3 uses the public key of the sender (terminal 1003) to confirm the digital signature for the received content confirmation information 13/3.
  • FIG. 13 is a flowchart for explaining the operation of the reception content confirmation information confirmation unit 103 i3 shown in FIG. 12.
  • FIG. 14 is a transmission content confirmation information creation unit 104 shown in FIG. 6 is a flowchart for explaining the operation of FIG.
  • FIG. 15 is a flowchart illustrating the operation of the reception content confirmation information creation unit 202] 3 shown in FIG. 12, and
  • FIG. 16 is a transmission content confirmation information confirmation unit shown in FIG. 5 is a flowchart for explaining the operation of 205/3. 44
  • FIG. 12 when the transfer information 11 1
  • the reception content confirmation information creation section 202/3 of the terminal 200 ⁇ generates the reception content confirmation information 13 ⁇ according to the flowchart shown in FIG. Specifically, in step SE1 ⁇ shown in FIG. 15, the reception content confirmation information creation unit 202iS inputs the reception content (transfer information 1 1/3). Thus, in step SE2 ⁇ , the message digest creation unit 202 ai3 compresses the received contents (transfer information 11] 3) with a hash function and outputs the message digest (FIG. 1). 1: Create transfer information MD J3 12 b ⁇ ). In the example shown in FIG. 15, the process may proceed from step SE1] 3 to step SE6jS without executing the process of step S ⁇ 2] 3.
  • ), Recipient information (recipient name, ID, public key ID, e-mail address, digital certificate, etc.) and communication information (transmission time, reception time, communication method, communication ID, etc.) are imported from transfer information 1 1] 3 .
  • the sender, communication, and receiver information acquisition unit 202b] 3 transmits the sender information, receiver information, and communication input in steps SE3j3 to SE5 / 3.
  • the received content confirmation information creation unit 202 which has acquired the information, sends the received content (transfer information 1 13), the transfer information MD 1 2b) 3, the sender information, the receiver information, the communication information, etc.
  • step SE7i3 the message digest creation unit 202a
  • step SE83 the digital signature adding section 202c encrypts the message digest created in step SE7 with the recipient's private key, thereby providing a digital signature to the message digest. Add a signature.
  • 3 the reception content confirmation information creation unit 202 ⁇ combines the information to create the reception content confirmation information 1 3] 3 shown in FIG. This is output to the information transmission section 203/3.
  • the message digest creation unit 202a / 3 transmits the transfer information MD ⁇ 1 2h ⁇ as necessary in the transmission content confirmation information confirmation unit 205] 3. Output to 0 5 a / 3.
  • the message digest creation / acquisition unit 205a / 3 acquires the transfer information MD ⁇ 12b ⁇ without creating a message digest.
  • the received content confirmation information 13 is transmitted to the terminal 100] 3 via the network N
  • the reception content confirmation information confirming unit 103 of the terminal 1003 detects tampering by confirming the content of the reception content confirmation information 13
  • step SC1 ⁇ shown in Fig. 13 the received content confirmation information confirmation
  • the recognition unit 103/3 proceeds to step SC2j3.
  • 3 the message digest creation unit 103 a] 3 decrypts the received content confirmation information 13 ⁇ using the recipient's public key, thereby obtaining the message digest ( Figure 11: Create (acquire) the transfer information MD ⁇ 12c ⁇ ).
  • 3 the digital signature verifying unit 103 c uses the public key of the receiver (terminal 200 i3) to digitally sign the received content confirmation information 13 i3 by the receiver. Check if it is.
  • the received content confirmation information 13 can be decrypted with the public key of the receiver (terminal 200/3), the received content confirmation information 1 3
  • the received content confirmation information 1 3; 3 cannot be decrypted with the recipient's public key, the received content confirmation information 1 3
  • the reception content confirmation information confirming unit 103 J3 determines the digital signature of the reception content confirmation information 13 ⁇ from the result of the confirmation in step SC3] 3 by the receiver (terminal 200). )), And if the result of the determination is “NO”, it is assumed that tampering or communication error has occurred.
  • step SC 5 ⁇ various information included in the received content confirmation information 13 ⁇ is classified.
  • the various types of information include received information content, the above-described sender information, receiver information, communication information, a message digest (transfer information MD ⁇ 12cj3), and the like. 47
  • the reception content confirmation information confirmation unit 10 3 i3 inputs the information on the sender, the communication information, the recipient information, and the like regarding the communication transferred to the step SC 6 (proceed to step 3 and transfer information 1 1) 3 by the sender. I do.
  • the message digest creation unit 103a of the reception content confirmation information confirmation unit 103] 3 compresses the transfer information 111 with a hash function and transfers the transfer information MD. Create ⁇ 12 a ⁇ (see Fig. 11). Then, the reception content confirmation information confirmation unit 10 3] 3 verifies the reception content for each information by comparing the reception content and the transmission content in steps SC 9 jS to SC 12.
  • step SC13] 3 the reception content confirmation information confirmation unit 1033 receives the verification results in steps SC9] 3 to SC12j3 and determines whether the reception content is different from the transmission content. If the result of the determination is “NO”, it is assumed that tampering or a communication error has occurred. On the other hand, if the received content is not different from the transmitted content, the received content confirmation information checking unit 10 3] 3 sets the determination result of SC 13] 3 to “YES” and determines that no tampering has occurred. I do.
  • the transmission content confirmation information creation unit 104] 3 executes processing for creating transmission content confirmation information 14 (see FIG. 11) according to the flowchart shown in FIG.
  • the transmission content confirmation information creation unit 104] 3 inputs the reception content confirmation information 13 ⁇ in step SD1 ⁇ shown in FIG. 14, and then transmits the reception content confirmation information approval information in step SD2] 3.
  • the reception content confirmation information approval information is information indicating that the reception content confirmation information confirmation unit 103 has approved (confirmed) the content of the reception content confirmation information 1 3] 3.
  • the information indicating this approval (confirmation) includes the time of approval, the terminal, the approver (in one embodiment, the sender). 48. Generated based on information about.
  • step SD3] 3 the transmission content confirmation information creation unit 1043 integrates the reception content confirmation information 13 ⁇ and the reception content confirmation information approval information.
  • step SD4] 3 the message digest creating unit 104a) 3 acquires the message digest of the information integrated in step SD3 ⁇ , and then proceeds to step SD53.
  • 3 the digital signature adding unit 104cJ3 performs a digital signature on the message digest by encrypting it with the secret key of the sender (terminal 100/3).
  • 3 transmission content confirmation information creating section 104/3 integrates the various information in step SD3 and the message digest digitally signed in step S S5 ⁇ .
  • the transmission content confirmation information creation unit 104 ⁇ creates transmission content confirmation information 14 ⁇ , and the transmission content confirmation information 14 4] 3 is output to the information transmission unit 1053 You.
  • the transmission content confirmation information 14) 3 is transmitted to the terminal 200 via the network ⁇ 3 by the information transmission unit 105/3, and then transmitted to the information reception unit of the terminal 200 3. 2 0 4; Accordingly, the transmission content confirmation information confirmation unit 205/3 of the terminal 200/3 confirms the transmission content confirmation information 14 ⁇ according to the flowchart shown in FIG.
  • step SF 13 the transmission content confirmation information confirmation section 205/3 receives the transmission content confirmation information 1 4] 3 received by the information reception section 204. After that, the process proceeds to step SF20.
  • step SF 2/3 49.
  • the message digest creation / acquisition unit 205a decrypts the message content confirmation information 14 ⁇ using the public key of the sender (terminal 100 ⁇ ) to generate the message digest. Create (acquire).
  • step SF3 / 3 the digital signature confirmation unit 205c / 3 uses the public key of the sender (terminal 100/3) to send the transmission content confirmation information 14
  • the transmission content confirmation information 14 ⁇ could be decrypted with the sender's (terminal 100] 3) public key, the transmission content confirmation information 14 4) 3 was digitally signed by the sender.
  • the transmission content confirmation information 1 4] 3 cannot be decrypted with the sender's public key, the transmission content confirmation information 14 is not digitally signed by the sender.
  • the transmission content confirmation information confirming unit 205/3 receives the digital signature of the transmission content confirmation information 14 from the confirmation result of step SF3
  • step SF5 various information included in the transmission content confirmation information 14 ⁇ is classified.
  • the various types of information include the contents of received information, the above-described sender information, receiver information, communication information, a message digest, and the like.
  • the transmission content confirmation information confirmation section 205 proceeds to step SF6] 3, and receives the transfer information 1 1] 3 received, the sender information related to the communication transferred by the sender, 50 Enter communication information, recipient information, etc.
  • a message digest creation and acquisition unit 205a of the transmission content confirmation information confirmation unit 205] 3 (3 is the transfer information 11 1) 3 compressed by a hash function
  • the transfer information MD] 3 1 2b ⁇ (message digest)
  • the message digest creation / acquisition unit 205a / 3 is used for the message digest creation unit 202a] 3
  • the transmission content confirmation information confirmation unit 205/5/3 performs steps SF 9/3 to SF 12 ⁇
  • the transmission content confirmation information confirmation unit 205 ⁇ checks the received content by comparing the transmitted content with the transmitted content in step SF13 / 3.
  • the reception content confirmation information 13 ⁇ the transmission content confirmation information Since tampering detection is performed using 140, even if the terminal does not have the right to decrypt the received information, it is possible to detect tampering of the information.
  • a tampering detection program for realizing the above-described functions is provided.
  • the program may be recorded on a computer-readable recording medium, and the falsification detection program recorded on the recording medium may be read and executed by a computer system to perform the falsification detection of the information.
  • the falsification detection program is recorded in its entirety or in part on a portable medium such as a floppy disk, CD-ROM, or a storage device such as a hard disk.
  • the tampering detection program is read by a computer, and all or part of the operation is executed.
  • the recording medium mentioned here is not limited to a medium in which a falsification detection program is statically recorded, such as a magneto-optical disk, but may also be a falsification detection program through a communication line such as an Internet dedicated line or a telephone line.
  • tampering detection is performed using the reception content confirmation information and the transmission content confirmation information, and thus the right to decrypt the received information is possessed. Even if the terminal does not, it can detect falsification of information.
  • the invention of the third embodiment relates to an encryption device, a decryption device, a method, and a recording medium for encrypting and decrypting information.
  • the following technology has been known. 52
  • confidentiality of this information may be required for information transmission. Therefore, various encryption schemes have been devised.
  • FIG. 33 shows an operation flowchart of an example of a conventional encryption device using a well-known encryption method. In the method of this example, the public key code method and the common key encryption method are used in combination.
  • the encryption device inputs a common key by the sender or generates a random key on the side of the encryption device to generate a common key and obtain the common key (step S 15 1 y) 0
  • the common key is encrypted using the public key of the receiver using public key cryptography, and is used as an encryption key (step S152y).
  • the plaintext is encrypted using the common key to generate a ciphertext (step S 1 5 3 7) o
  • a plaintext is compressed using a hash function to create a message digest MD ⁇ (step S154y).
  • a digital signature is added by encrypting the MD 7 with the private key of the sender (step S155y).
  • FIG. 34 shows an operation flowchart of a decryption device using a decryption method corresponding to the encryption / digital signature method.
  • the decryption device Upon receiving the encryption key, the ciphertext, and the digital signature, the decryption device first decrypts the encryption key using the recipient's private key to obtain a common key (step S161 ⁇ ).
  • the ciphertext is decrypted by using the common key to obtain a plaintext (step S 1 62 ⁇ ) c 53.
  • the plaintext obtained by decryption is compressed with a hash function, and the message message MD
  • step S 1647 the digital signature of the received message digest MD ⁇ is decrypted with the sender's public key to obtain MDy (step S 1647) 0
  • this MDY is compared with the previous MD' ⁇ to verify that the original plaintext has not been tampered with.
  • identity verification can confirm the identity of the plaintext celebrity.
  • FIG. 35 shows the information composed of ⁇ data parts (plaintext) and the structure of the encrypted information generated from this information.
  • the encryption information in this case includes an encryption key corresponding to each data packet, a ciphertext of the data part, and a digital signature of the data part.
  • the size of a digital signature attached to a 69-byte data part is 23,299 bytes.
  • the present invention has been made in view of the above points, and can reduce the overhead of encrypted information obtained by encrypting information including a plurality of data parts (plain text), and can be used by a plurality of users. It is an object of the present invention to provide an encryption device, a decryption device, a method, and a recording medium which are capable of simultaneously verifying and falsifying each data part for falsification.
  • a third embodiment will be described with reference to the drawings.
  • FIG. 19 is a block diagram illustrating a configuration of an encryption device and a decryption device according to an embodiment of the present invention.
  • the encryption / decryption device 10 T / of the present embodiment includes a key encryption unit 11 ⁇ , a key decryption unit 12 ⁇ , an encryption unit 13 ⁇ , and a decryption unit 14 ⁇ .
  • the key encryption unit 11 ⁇ is composed of the common key acquisition unit 15 ⁇ , the common key encryption unit 16 ⁇ , and the first It is composed of a common key tampering detection information creation unit 1.7 ⁇ as a tampering detection information creation unit.
  • the key decryption unit 12 ⁇ is composed of a common key decryption unit 18 ⁇ , a common key falsification information creation unit 19 ⁇ as a second common key falsification detection information creation unit, and a falsification as a first falsification verification unit.
  • the verification unit consists of 20 ⁇ .
  • the encryption unit 13 ⁇ includes a data encryption unit 21 ⁇ and a data tampering detection information creation unit 22y as a first data tampering detection information creation unit.
  • the decryption unit 14 V is composed of a data decryption unit 23 y, a data tampering detection information creation unit 24 7 as a second data tampering detection information creation unit, and a tampering verification unit 25 ⁇ as a second tampering verification unit.
  • the common key acquisition unit 15 ⁇ acquires or generates a common key used for encryption.
  • the common key is generated using, for example, a random number generation device or the like.
  • the common key encryption unit 16 ⁇ encrypts the common key using a public key code system such as the RS ⁇ system or the elliptical system.
  • the public key used for encryption uses the public key of the member who shares the information.
  • the common key is encrypted using the public keys possessed by the three members, and three encryption keys are created.
  • the common key tampering detection information creation unit 17 ⁇ creates key information to be used for verifying the validity of the common key (1. not falsified, 2. created by a valid user, etc.).
  • the common key was compressed with a hash function such as MD5 or SHA-1 to create a message diage MDy of the common key, and a digital signature was applied to this MD using the secret key of the common key creator. Can be used as key information.
  • a digital signature method such as DSA may be used in addition to the public key encryption method.
  • the common key decryption unit 18 ⁇ decrypts the encryption key encrypted by the common key encryption unit 16 ⁇ using a public key cryptosystem.
  • the secret key used for decryption the secret key of the user who performs decryption is used.
  • Common key falsification detection information creation unit 1 9 56 y creates common key falsification detection information used to confirm the validity of the common key. For example, a message digest MD′ ⁇ is created by compressing the common key decrypted by the common key decryption unit 18 ⁇ with a hash function.
  • the tampering verification unit 20 ⁇ is shared by comparing and verifying the key information (for example, MDT) and the common key falsification detection information (for example, MD'y) created by the common key falsification detection information creation unit 19 ⁇ . Check the validity of the key. In order to confirm the validity of the common key, it is necessary to confirm the validity of the creator of the common key itself, but this is specified separately.
  • the data encryption unit 21 ⁇ encrypts the data parts (plaintext) using a common key cryptosystem to generate a ciphertext.
  • the common key used for encryption uses the common key obtained or generated by the common key acquisition unit 15 ⁇ , and when using existing encryption information, the common key decryption The common key decrypted by the decrypting unit 18 ⁇ is used.
  • the data tampering detection information creation section 22 creates first data tampering detection information for verifying whether the data parts have been tampered with. For example, a message digest obtained by compressing a data part using a hash function, partial information extracted from the data part, an ID number, and the like can be used as the first data tampering detection information.
  • the data decryption unit 23 decrypts the ciphertext using the common key cryptosystem.
  • the data tampering detection information creation unit 24 ⁇ generates second data tampering detection information corresponding to the first data tampering detection information to verify whether the data parts have been tampered with. For example, a message digest created by compressing the original data decrypted by the data decryption unit 23 y using a hash function, partial information extracted from data parts, ID number etc. 57
  • the falsification verifying unit 25 ⁇ checks the validity of the original data part by comparing and verifying the first data falsification detection information and the second data falsification detection information.
  • the common key encryption unit 16 V and the data encryption unit 21 ⁇ may be realized by the same device.
  • the common key decryption unit 18 ⁇ and the data decryption unit 23 ⁇ may be realized by the same device.
  • the common key tampering detection information creation units 17 ⁇ and 19 ⁇ or the data tampering detection information creation units 22 ⁇ and 24 ⁇ may be realized by the same device.
  • the encryption / decryption device according to the present embodiment may be realized and used as an independent device instead of a single device.
  • the encryption device according to claims 51 and 52 can be composed of a key encryption unit 11 # and an encryption unit 13y. Further, the encryption device according to claim 53 can be configured by a key encryption unit 11 1, an encryption unit 13 ⁇ , and a key decryption unit 12.
  • the decryption device according to claims 54 and 55 can be composed of a key decryption unit 12 and a decryption unit 14 ⁇ .
  • FIG. 20 shows a use form of the encryption / decryption device 10 ⁇ of the present embodiment.
  • an information storage device 30 ⁇ composed of a server and other terminal devices connectable to the network, and a terminal device 317 provided with an encryption / decryption device 10 ⁇ are connected via a network.
  • the information storage device 30 ⁇ includes a non-volatile recording device such as a hard disk or a magneto-optical disk, and can store cipher text, data tampering detection information, an encryption key, key information, and related information as encryption information. .
  • input to the terminal device 3 1 ⁇ as a peripheral device.
  • the input device refers to an input device such as a keyboard and a mouse.
  • the display device refers to a cathode ray tube (CRT) or a liquid crystal display device.
  • the encrypted information may be stored in the local terminal device 31 ⁇ and used for a standalone loan.
  • the common key obtaining unit 15 ⁇ obtains a common key or generates a common key by input from the outside of the encryption / decryption device 10 ⁇ (step S 3 0 1 y) 0
  • the key encryption unit 16 ⁇ generates an encryption key obtained by encrypting the common key using the public key of the user obtained in advance via the network (step S302y). ).
  • the common key tampering detection information creation unit 17 ⁇ creates information about the common key creator, such as the secret key of the common key creator, as key information as common key tampering detection information (step S303T). .
  • Data encryption unit 2 1 ⁇ encrypts data part 1 ⁇ (plaintext) and encrypts 59
  • step S 304 y is generated (step S 304 y), and the data tampering detection information creation section 22 ⁇ creates data tampering detection information 1 y that is information on data part 1 ⁇ from data part ly (step S 304). 305).
  • step S 304y the process from step S304y to step S305y is repeated n times.
  • a set of ciphertexts 1, 2, ' ⁇ , n, data tampering detection information 1, 2, ⁇ , n, key information, and an encryption key is transmitted to the information storage device 30 y as encryption information ( Step S306 y).
  • the above explanation is for a single user and a single type of encryption key.
  • step S302 ⁇ m kinds of encryption keys are generated using the public key of each user. That is, an encryption key corresponding to each user is generated.
  • Figure 22 shows the structure of the information before encryption and the structure of the encrypted information.
  • the data parts 1, 2,..., N before the encryption are used, and the encrypted information is ciphertext 1, 2,..., N and the data tampering detection information 1, 2,. ⁇ , N and encryption keys 1, 2, ⁇ , m and key information are created.
  • the operation of the encryption / decryption device 10 # when decrypting the encryption information including the ciphertext of a plurality (n) of data parts will be described with reference to the operation flowchart of FIG. .
  • This process can be performed by the person who owns the private key that is paired with the public key used to create the encryption key. ' 60
  • the encryption / decryption device 10 ⁇ acquires the encryption information stored in the information storage device 30 ⁇ (step S501y).
  • the encryption key included in the encryption information is associated with a user name, a user ID, and the like, and the encryption key corresponding to the user is transmitted from the information storage device 30 y to the encryption / decryption device 10 ⁇ .
  • the common key decryption unit 18 ⁇ decrypts the encryption key using the user's secret key to obtain a common key (step S502y).
  • the common key tampering detection information creating unit 19 # creates common key tampering detection information from the common key obtained in step S502 ⁇ (step S503 ⁇ ).
  • the tampering check part 2 0 gamma is common key falsification detection information to verify compare verifies the validity of the key generator (step S 5 0 4 y) 0 In this case the acquired key information, two pieces of information match By doing so, the legitimacy of the key creator can be determined. If it is determined in step S504 ⁇ that the key creator is valid, the following processing is sequentially performed on a set of ⁇ ciphertexts and ⁇ data tampering detection information.
  • the data decryption unit 23 ⁇ decrypts the ciphertext using the common key (step S505y) c. Then, the data tampering detection information creation unit 24 converts the decrypted data parts into (Step S506y) c
  • the data tampering detection information created here is referred to as first data tampering detection information
  • the data tampering detection information held as the 61st information is referred to as second data tampering detection information.
  • the falsification verification unit 25 ⁇ compares the generated first data falsification detection information with the second data falsification detection information that is a part of the encrypted information, and verifies whether the falsification has been performed (step S5). 0 7 y).
  • step S508y the decrypted data pad (plaintext) is output (step S508y).
  • the encryption key is associated with the user name, user ID, etc., so that the key decryption unit 12 ⁇ / uses only the encryption key corresponding to the user. .
  • the above steps S502T to S504 Set y as follows. First, in step S502y, all the encryption keys are decrypted.
  • step S503y common key tampering detection information is created for all of the common keys generated in step S5207.
  • step S504 / each common key falsification detection information and key information are compared and verified. When all the combinations are different, it is known that tampering has been performed, and if there is a match, the corresponding common key is known to be a formal common key.
  • the encryption information is created from the data bytes 1, 2, ..., n described above.
  • an encryption key and key information are obtained from the information storage device 30 ⁇ in which the encryption information is stored (step S601 ⁇ ).
  • the encryption key included in the encryption information is associated with a user name, a user ID, and the like, and the encryption key corresponding to the user is transmitted from the information storage device 30 ⁇ to the encryption / decryption device 10 ⁇ . Shall be granted.
  • the common key decryption unit 18 ⁇ decrypts the encryption key corresponding to the user using the user's private key (step S602y).
  • the common key falsification detection information generator 1 9 gamma to create a common key falsification detection information from the common key obtained in step S 6 0 2 ⁇ (Step S 6 0 3) 0 tampering verification unit 2 0 gamma is Then, the key information and the common key tampering detection information are compared and verified to see if they match, and the validity of the key creator is verified (step S640). In this case, the validity of the key creator can be determined by matching the two information.
  • step S604 ⁇ If it is determined in step S604 ⁇ that the key creator is valid, the data encryption unit 21 ⁇ encrypts the added data part ⁇ + 1 to generate a ciphertext ⁇ + 1 (step S 6 0 5 y) c Further, data tampering detection information creation unit 2 2 ⁇ is tampered with data part ⁇ + 1 63. Create detection information n + 1 (step S606g).
  • step S605y If the number of data parts to be added is L, the processing from step S605y to step S660y is repeated L times c and the ciphertexts n + 1, n + 2, ... ', n + L and tampering detection information n + 1, n + 2, ...
  • N + L are transferred to the information storage device 30 T and additionally stored as encrypted information (step S 607 y).
  • the key decryption unit 12 ⁇ uses only the encryption key corresponding to the user by associating the encryption key with the user name, the user ID, and the like.
  • the above steps S602 y to S6 0 4 make y as follows. First, in step S602 ⁇ , all the encryption keys are decrypted. When a plurality of encryption keys are decrypted in step S62027, a plurality of common keys including an unauthorized one are generated.
  • step S603y common key tampering detection information is created for all the common keys generated in step S6207.
  • step S604 each piece of common key falsification detection information and key information are compared and verified. When all the combinations are different, it is known that tampering has been performed, and if there is a match, the corresponding common key is known to be a formal common key.
  • Figure 25 shows the configuration before and after the encryption information is added.
  • the ciphertext n + 1, n + 2,..., N + L and the data tampering detection information n + 1, n + 2,. Indicates that it has been added to the encryption information.
  • the operation of the encryption / decryption device 10 ⁇ when adding a shared member to the team sharing the encryption information stored in the information storage device 30 ⁇ is shown in the operation flow shown in Figure 26. This will be described with reference to the chart. Here, a case will be described in which a shared member ⁇ adds a shared member C as a new shared member to a team to which the shared members ⁇ and ⁇ belong.
  • the encryption / decryption device 10 y accesses the information storage device 30 ⁇ by operating the shared member 1 to obtain the key information and the encryption key ⁇ corresponding to the shared member 1 (step S810 [gamma]).
  • the common key decryption unit 18 ⁇ decrypts the encryption key ⁇ using the secret key of the shared member who is the receiver to obtain a common key (step S 802 y) c Common key falsification detection information
  • the creating unit 19 ⁇ creates common key falsification detection information from the common key (step S803 ⁇ ).
  • the falsification verifying unit 20 ⁇ compares and verifies the acquired key information and the common key falsification detection information to confirm the validity of the key creator (Step S804y). In this case, it is verified that tampering has not been performed by matching the two information.
  • step S804 ⁇ when the validity of the key creator is confirmed, common key encryption section 1667 encrypts the common key using the public key of shared member C to be added as a shared member, and performs encryption. Generate the encryption key C (step S805y).
  • the key encryption unit 1 2 ⁇ transfers the generated encryption key C to the information storage device 30 ⁇ 6 ⁇ (Step S806 ⁇ ).
  • the encryption keys A, B, and C corresponding to the three shared members are stored in the information storage device 30 ⁇ , and thereafter, the added shared member C is assigned to the team encryption key.
  • Reference to modification information ⁇ Change etc. can be performed.
  • Figure 27 shows the configuration of encrypted information before adding shared member C and the configuration after adding shared member C.
  • the encryption key C for the shared member C which is a new shared member, is added to the original encrypted information as the encrypted information.
  • the operation of the encryption / decryption device 10 ⁇ when deleting a shared member will be described with reference to the operation flowchart shown in FIG.
  • the encryption / decryption device 10 # acquires a deletion command for deleting the shared member by the input operation of the shared member 10 (step S101 ⁇ ).
  • the data tampering detection information creation unit 2 2 ⁇ creates data tampering detection information corresponding to the delete instruction of the shared member ((step S 10 2 ⁇ ) 0
  • the encryption / decryption device 10 ⁇ The deletion information, which is a set of the shared member deletion instruction and the data tampering detection information serving as identification information for identifying the person who issued the deletion instruction, is transferred to the information storage device 30 ⁇ (step S103 ⁇ ).
  • the information storage device 30 has a function to identify the person who issued the deletion command. 66. It is assumed that the encryption key corresponding to the deletion instruction can be deleted. Further, as the data tampering detection information used here, the digital signature of shared member B for the delete instruction of shared member A may be used.
  • the information storage device 30 uses an ID, a password, or the like as identification information for identifying the person who issued the deletion instruction, and checks the information storage device 30 with the identification information registered in the information storage device 30 ⁇ . Moore.
  • Figure 29 shows the configuration of the encrypted information before deletion of shared member ⁇ and the configuration after deletion. Here, it is shown that the encryption key A for the shared member A has been deleted from the original encryption information as the encryption information.
  • the operation of the encryption / decryption device 10 ⁇ according to the present embodiment will be described in detail using a specific example.
  • user ⁇ is scheduled to be shared by team 101 ⁇ (three users ⁇ , B, and C belong) on October 1, 1998
  • the process when adding the terms "Seminar one participation" and "1 5: 0 0" to the item of is explained.
  • the information on the schedule includes encrypted information and unencrypted information.
  • the encryption / decryption device 10 ⁇ used by the user B includes an input unit (not shown) for receiving data input by the user ⁇ and a display unit (not shown) for displaying information. And First, the user ⁇ accesses the information storage device 30 y from the encryption / decryption device 10 ⁇ , and confirms whether or not he / she can access the schedule of October 1998 of team 101 y. If accessible, access Team 1 October 1's October 1998 schedule.
  • the information storage device 30 ⁇ transfers the schedule of October 1998 of Team 1998 to the encryption / decryption device 10 ⁇ , and the encryption / decryption device 10V displays its information. To display the schedule. At this stage, it is assumed that the schedule information has not been encrypted yet.
  • User ⁇ ⁇ uses the input unit of the encryption / decryption device 10 ⁇ to input “Seminar one participation” and “15: 0 00-” in the item on October 1, 1998. .
  • a common key is generated in the common key encryption unit 16 ⁇ . In this embodiment, this common key is called cKey1y.
  • the common key encryption unit 16 y encrypts the public keys of the user A, user B, and user C using, for example, the public key cryptosystem RSA.
  • the common key encryption unit generates three encryption keys corresponding to three users.
  • these encryption keys are referred to as eKeylAy, eKey1B ⁇ , and eKey1Cy, respectively.
  • the common key tampering detection information creation unit 17 ⁇ creates MD ⁇ , which is a message digest of the common key, and further uses this MD ⁇ with the digital signature of the user's private key.
  • the c data encryption unit 21 ⁇ in which the MD y that performed the digital signature is the key information is Signed K eyly uses the schedule data “seminar one participation” as the common key c K ey 1 Encrypt with ⁇ , ciphertext C rypt D a 68. Generate ta1y.
  • the data tampering detection information creation unit 22 ⁇ generates a message digest of “participation in seminar” Message D1 ⁇ using MD5 which is a hash function.
  • the procedure applied to "Seminar One Participation" is performed on the schedule data parts "15: 0 00-", and the encrypted text Crypt D ata 2 y of ⁇ 15: 0 00- "and the message digest Lead M essage D 2 /.
  • the information is transferred from the encryption / decryption device 10 ⁇ to the information storage device 30.
  • the configuration of the information stored in the information storage device 30 ⁇ at this time is shown in FIG.
  • Information for distinguishing the schedule created in the above processing, user ID and encryption key, key information, ciphertext, data tampering detection information and related information are stored.
  • the user ⁇ is added to the encrypted information created in the third embodiment by the team 101 (users A, B, Explains the processing when adding the terms “meeting” and “17: 00: 00-” to the items on October 2 of 199 8 in the schedule shared by the three members of C) I do.
  • the user A accesses the information storage device 30 from the encryption / decryption device 10 ⁇ , and confirms whether the user can access the schedule of the team 101 ⁇ in October 1998. 69
  • Information storage apparatus 3 0 T transfers the encryption key e K ey 1 A ⁇ and the key information S igned K eyl 7 to the encryption decoder 1 0 ⁇ .
  • User ⁇ uses the input section of the encryption / decryption device 10 ⁇ to enter “meeting” and “ 17:00:00” in the business item on October 2, 1998.
  • the common key decryption unit 18 ⁇ decrypts the encryption key eKey1 1 ⁇ by using the secret key of the user ⁇ to generate the common key cKey1 ⁇ .
  • the common key tampering detection information creation unit 19 ⁇ creates a message digest key D1′ ⁇ of the common key cKeyly.
  • the falsification verification unit 20 ⁇ decrypts the Keyed Keyly of the key information using the public key of the user B, and obtains the message digest key Dly of the common key before encryption. Then, the key D ly is compared with the key D l ' ⁇ . If the key D ly and the key D l 'y are equal, it is understood that the common key created by the user ⁇ ⁇ ⁇ belonging to the team 101 ⁇ can be obtained without tampering. Thus, the validity of the common key can be confirmed. Here, it is necessary for the user to determine whether the creation of the common key is legitimate, that is, to confirm the validity of the common key creator itself as information for confirming the validity of the common key creator. is there.
  • the fact that the common key creator is the user ⁇ is displayed as a dialog box on the display unit of the encryption / decryption device 1 ⁇ . And ask the user to confirm it, or from the information storage device 30 via a network. 70 It may be obtained as related information.
  • the data encryption unit 21 encrypts the “conference”, which is the data part of the schedule, with the common key cKey1 ⁇ , and generates a ciphertext CryptData3y.
  • the data tampering detection information creation unit 22 ⁇ generates, for example, a message digest Message D3 of "conference" using MD5 which is a hash function.
  • the team ⁇ ⁇ ⁇ created in the third and third embodiments and stored in the information storage device 30 y 1 998 10 10 The process when user C refers to the month schedule will be described. First, user C sends an error message from encryption / decryption device 10 ⁇ to information storage device 30 y. 71. Make sure you have access to the schedule for October 1980 on Team 101 ⁇ . If it is accessible, access the schedule of October 1998 in Team 101 ⁇ .
  • the information storage device 30 ⁇ encrypts and decrypts the schedule of the October 1 198 October 1998 and the encryption key e K ey 1 C ⁇ and key information S igned ⁇ ey 17 Transfer to device.
  • the common key decryption unit 18 y decrypts the encryption key eKey1Cy using the secret key of the user C to obtain the common key cKey1 ⁇ .
  • a message digest cKeyD'v of the common key cKey1 ⁇ is created by the common key tampering detection information creation unit 19 ⁇ .
  • the falsification verifying unit 20 ⁇ decrypts the Signed Keyy using the public key of the user B to obtain a message digest cKeyD ⁇ of the common key before encryption.
  • this message digest cKeyDy is compared with the previous message digest cKeyD' ⁇ . If these two message digests are equal, it can be verified that the common key cKey1 ⁇ created by the user ⁇ belonging to team 101 ⁇ can be obtained without tampering. That is, the validity of the obtained common key can be confirmed. Also, here, it is necessary to confirm the validity of the symmetric key creator itself, as described in the third-second embodiment.
  • the data decryption unit 23 ⁇ decrypts the ciphertext Crypt D ata 17 using the common key cK ey 17 obtained from the common key decryption unit 18 ⁇ . 72 This is where the plaintext "participation in the seminar" is obtained.
  • the data tampering detection information creating unit 24 ⁇ generates a plaintext message digest Message Dl' ⁇ using MD5 which is one of the hash functions.
  • the message digest message D17 transferred from the information storage device 30 ⁇ is compared with the message digest message D1′ ⁇ generated by the data tampering detection information creation unit 24 ⁇ . If these two message digests are equal, it can be understood that the data parts created by the person belonging to team 101y can be obtained without tampering.
  • Figure 32 shows a display example of the schedule after decryption.
  • the data part “Seminar Participation” entered by User B, “15: 00-” and the data part entered by User A “Conference”, “17: 00-” Can be seen by User C, who belongs to the same team.
  • shared members belonging to one team can freely add or change data parts for encrypted information, refer to data parts of other shared members, etc.
  • Confidentiality As an example, each size of lessage D ly,-., Message D 4 y is 16 bytes, and the size of key information is 230 bytes (there is a lower limit). 73. In this example,
  • the method of the present invention can reduce the amount of information compared to the conventional method.
  • the invention of the third embodiment may use a LAN or a dial-up network in addition to the Internet.
  • a program for realizing the encryption device, the decryption device, and the method of the present invention is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into a computer system. Encryption by executing
  • decoding processing may be performed.
  • the encryption program uses a common key encryption method to obtain or generate a common key used for encryption and a public key encryption method.
  • the function to create the first data tampering detection information from the plain text is realized by the computer.
  • the decryption program decrypts the encryption key using a public key cryptosystem and a function of decrypting the encryption key.
  • a computer is provided with a function of performing tampering verification based on the information and the second data tampering detection information.
  • falsification detection information is not created for each plaintext, and a key serving as falsification detection information is provided for a common key for encrypting each plaintext.
  • the inventions of the fourth to fourth embodiments are to create, manage, and create a team data list for hierarchizing teams such as departments and sections of a company composed of a plurality of users (members).
  • a team data list processing system for storing and sharing various information and various functions provided to users safely among users. More specifically, a team data list storage device that is responsible for processing related to the storage of team data lists, and a team data list that performs various management on the team data list obtained from the team data list storage device
  • the present invention relates to a system including a management device.
  • the following techniques have been known. 75-In order to share various resources such as various functions and information provided to users among multiple users, the user requesting access to these resources has the right to truly access the resources. It is necessary to provide a function for verifying whether or not there is a check.
  • FIG. 51 shows an overview of a conventional system that uses ACLs to share information among multiple users.
  • the intranet 1 ⁇ and the internet 2 ⁇ are connected to the server 56 via firewalls 36 and 4 ⁇ , respectively, and only those inside the intranet 1 ⁇ are connected. Instead, shared members 6 ⁇ outside the intranet share information with each other via the internet 2 ⁇ .
  • intranet 1 is a closed network such as a network established in a company, while Internet 2 ⁇ is a public network that spans the globe. is there.
  • the firewalls 30 and 4 ⁇ are computers to prevent malicious intruders from illegally accessing the intranet 1 ⁇ .
  • the server 5 is a terminal (computer) in which various resources are stored, and includes a database 7 storing shared information, a group that can access specific information or functions, and members belonging to the group. It has ACL 8 ⁇ that holds the member list.
  • This server 5 ⁇ is stored in database 7 76
  • the user authentication function that verifies whether the communication partner corresponding to the client is a previously authorized person, and the access to shared information based on ACL8 ⁇ . It has an access control function that verifies the feasibility and a group management function that enables only members belonging to a specific group to access specific shared information based on ACL8 ⁇ .
  • the server 5 ⁇ performs user authentication by referring to the ACL 8 ⁇ each time. If the user is defined as a member in ACL 86, access is permitted.
  • the server 5S checks ACL 8 ⁇ to see if the member is included in a specific group, and if the member has an access request. They try to determine whether they are allowed to access shared information.
  • the server-side administrator it may not be preferable to include the server-side administrator as a sharing member. For example, a system administrator belonging to the information system department of a certain company may not be able to access the company's personnel information that should be shared only within the human resources department.
  • the administrator of the server 5 ⁇ is authorized to set and manage the ACL 86.
  • the server administrator 5 ⁇ can make unauthorized access to the ACL 8 ⁇ , and it is impossible to prevent the setting contents of the ACL 8 ⁇ from being tampered with intentionally.
  • the server SV 77 In addition to this, besides the server administrator, the server SV 77
  • each section may be divided into several groups for different tasks.
  • it is very burdensome for the director of development to manage each section and the members of all groups belonging to each section. Therefore, in order to distribute such management burden, some people are assigned to assist the director of the development department, and these people are assigned to perform part or all of the management work.
  • the director of the development department is given only authority to perform tasks such as section creation and consolidation, and the internal management and information sharing itself of the section is left to the section manager and group leaders below it. Have been.
  • the conventional system described above has a problem in that flexible management and information sharing suitable for the organizational form of the company as described above are not considered at all.
  • the present invention has been made in view of the above points, and its purpose is to provide a server. 78 Preventing persons outside the team corresponding to the organizational unit of the company, including crackers, including crackers, etc. It is to provide a team data list processing system for realizing the functions. More specifically, only those who are specifically selected from the members who belong to each team can create sub-teams under the team, assign sub-team creation rights to specific persons, create sub-teams, etc.
  • An object of the present invention is to provide a team data list processing system that allows a specific person selected by an authority to manage a sub-team.
  • the fourth to fourth embodiments will be described with reference to the drawings. First, the team data list in the present invention will be described.
  • the team data list according to the present invention is a general term for a list that defines information about a team, and refers to a “set of members” applied to applications requiring highly confidential management such as the ACL described above. It is for definition. As described above, in the conventional system, terminal managers, network managers, and server managers who are not members of the team can change information about the team. On the other hand, in the team data list according to the present invention, information on the team is divided into a plurality of lists (authority list, authority data and member list, team master list, application list as described later) and managed. By doing so, team management such as layering the team and changing the team master itself can be performed only by members of the team.
  • a sub-team can be created under a team, thereby realizing a mechanism for simulating a hierarchical relationship in a company organization or the like and sharing information.
  • a plurality of specially selected humans A mechanism has been realized to grant the authority to create sub-teams to 79, thereby distributing the management burden so that the load is not concentrated on one administrator.
  • a mechanism has been implemented in which the sub-team creation authority is assigned to a specific person selected from within the sub-team for management within the sub-team. By doing so, the team manager does not need to be involved in managing and sharing information within the sub-team.
  • persons who can access the team data list are classified into three types, members, sub-authorities, and team masters, according to the contents of the authority, according to the hierarchical team.
  • the authority granted to the team data list is classified into three types, members, sub-authorities, and team masters, according to the contents of the authority, according to the hierarchical team.
  • the team master is the manager of a certain team and has the administrative authority to create sub-teams under the team.
  • a sub-authority is a person designated by the team master, and has the same administrative authority as creating a sub-team, like the team master, but is not allowed to appoint another person as a sub-authority. .
  • general members other than the sub-solar and the team master are those who share information and functions, and are not granted any privileges such as the right to create sub-teams.
  • the sub-solarity and team master are still members of the power team to which special authority is given, and in that sense the sub-solarity and team master are sometimes called members.
  • FIG. 37 is a block diagram showing the configuration of the entire system of the present embodiment including the team data list management device and the team data list storage device.
  • the team data list management device 300 and the team data list storage device 31 ⁇ have a team data list management function and a team data list storage function, respectively, which are described in detail below. Data is exchanged between each other using the communication function.
  • Both the team data list management device 30 ⁇ and the team data list storage device 31 ⁇ can be realized by a general computer such as a workstation, and the main memory of these computers respectively.
  • Stores programs (team data list management program, team data list storage program) for implementing the team data list management function and team data list storage function.
  • These programs are stored in portable storage media such as floppy disks, IC (integrated circuit) cards, magneto-optical disks, CD-ROMs (compact disks—read only memory), and hard disks built into computers. Some or all of them are stored in a computer-readable storage medium such as a large-capacity storage medium. That is, the program may be for realizing a part of the functions described in detail below, and further, these functions may be realized in combination with a program already recorded in the computer. Is also good. And
  • these programs are transferred from the storage medium to the main memory in advance under the direction of the CPU (central processing unit) on the computer. After that, the CPU executes the program transferred to the main memory, and thereby each part of the device is executed. 81 ⁇ is controlled to implement various processes described in detail below.
  • the “computer” mentioned here includes the OS (operating system) and hardware such as peripheral devices.
  • the computer-readable storage medium is not limited to those which statically store the program as described above, but may be dynamically stored for a short period of time through a communication line such as a dedicated line or a telephone line.
  • Main memory built into computer equipment such as servers, routers, and gateways that hold, transfer, and relay programs and data over networks such as the Internet, cache memory, servers, and clients. It includes all those that can hold programs for a certain period of time, such as volatile memory inside a computer that functions as such.
  • a storage device 32 ⁇ capable of constructing a database such as a hard disk is connected to the team data list storage device 31 ⁇ shown in FIG. 37.
  • the storage device 32 ⁇ stores a set of a team data list including a priority data 33 ⁇ and a priority list 34 ⁇ for each team composed of a plurality of members. Although only one set of authority data 33 ⁇ and authority list 34 ⁇ is shown in the figure for convenience of explanation, there are actually as many such sets as the number of teams.
  • FIGS. 38 3 and ⁇ show the detailed structure of the authority data 33 ⁇ and the authority list 34 ⁇ .
  • FIGS. 38C and 38D show notations for simplifying the stored contents of the authority data 33 ⁇ and the authority list 34 ⁇ in the following drawings. Things.
  • the authority data may be abbreviated as “AUD 0” and the authority list may be abbreviated as “AU L 0”.
  • the solitary data 33 ⁇ is data representing the relationship between a certain team and the sub-teams under it, and the team that ranks higher in the relationship with the sub-team is called the parent team.
  • the symbol "AUD ⁇ " indicates that the data is authority data
  • the authority data 33 ⁇ is a team ID 33 a ⁇ which is an identifier assigned to its own team.
  • Parent team ID 3 3 b ⁇ which is the team ID assigned to the parent team of this team
  • team creator 3 3 c 0 which means who created this team, members belonging to this team
  • the team master 33 d ⁇ that indicates to whom the team master authority was given, and the digital signature 33 eS that is digitally signed by the team creator 33 c ⁇ are included.
  • this authority data relates to Team 102 ⁇ which is a sub-team of Team 101 ⁇ .
  • the digital signature indicates that the team creator of this authority data is member ⁇ 6, and that the team master is member X ⁇ .
  • the authority list 340 is a list in which a plurality of managers in each team are registered, and includes data on the team master and sub-authority of the team.
  • the symbol “AUL ⁇ ” means the authority list
  • the authority list 34 ⁇ is the team ID 34 a ⁇ , team master 34 b ⁇ , sub-author for this team.
  • the team data list has a structure divided into AUDS, which is a list indicating the relationship between the parent team and sub-team, and AUL ⁇ , which is a list relating to sub-team management. I have.
  • the authority data 33 ⁇ and the authority list 34 ⁇ include the creation time of these data and list in addition to those shown in Fig. 38 3, 38 ⁇ , 38C, 38D. Timestamp, the digital signature algorithm used to create the digital signature 33 e ⁇ and the digital signature 34 d ⁇ , the validity period of the authority data 33 ⁇ and the authority list 34 4 ⁇ itself, and It contains data on the identification data of the individual solitary data 33 ⁇ and the authority list 34 ⁇ ⁇ itself. Also, as IDs (identifiers) for identifying members, sub-authorities, and team masters, there are various types such as names, e-mail addresses, organizational names, serial numbers of individuals, digital certificates, and the like. Can be used. Next, Fig.
  • the team hierarchy has a tree structure like a computer file system.
  • the ellipse in the figure represents the team, and the parent team and its sub-teams are connected to each other by a straight line. ing. Multiple sub-teams can be registered for each team. For example, sub-teams such as HR Division 1 and HR Division 2 can be registered under the HR team.
  • “Route ⁇ ” or “Route ⁇ ” is not used in the present embodiment, like a root directory on the file system. We call it a team.
  • both the team 102 ⁇ and the team 103 ⁇ are subteams of the team 101 ⁇ , and belong to the same hierarchy on the tree. Meanwhile, 84
  • FIG. 40 shows specific values for each team's authority list authority data corresponding to the team hierarchy shown in FIG.
  • a member list showing a list of shared members sharing information and functions with each other
  • the team data list is composed of three types of lists: authority list, authority data, and member list.
  • Each member list 101m6 to 104m0 shows a digital signature and a list of members of the creator of the member list, but there are various other members that match the purpose of use of the team.
  • each member list includes information about each member, such as e_mai 1 (e-mail) address @ your own address. By using these, information resources for each member can be obtained. Management can be done at the same time. According to the configuration shown in the drawing, by connecting the parent team ID described in the authority data, the team 101 ⁇ as the root can be reached from any of the sub-teams. In addition, for each team, multiple managers can create sub-teams.
  • team master ⁇ and sub-authorities B and C have the authority to create sub-teams, and As can be seen from the digital signature of the data 102 d S and 103 d ⁇ , the sub-teams 102 ⁇ and 103 ⁇ are created by the sub-authorities B and C of the team 101, respectively. are doing.
  • the authority data for a sub-team is to be created by the manager registered in the parent team for that sub-team.
  • anyone in the sub-team can become the team master of this sub-team at the direction of the parent team manager.
  • the digital signature of authority data 104 d6 is member V, sub-solarity V, one of the administrators of parent team 1 ⁇ 3 ⁇ , has authority data 1 04 d ⁇ has been created, and member L is nominated as the team master of team 104 ⁇ .
  • the authority list is created and digitally signed by the team master of each team.
  • the authority list 103 u ⁇ of team 103 is created by member X ⁇ who is the team master, and has a digital signature of member X ⁇ .
  • the member X can manage the data on the sub-solarity in the authority list 103 ⁇ ⁇ , and the manager of the parent team 101 ⁇ (ie, the team master ⁇ and the sub-authority) There is no interference from B, C).
  • the digital signer of the authority list is the creator of the team (ie, the team master or sub-authority of the parent team), for example, the HR manager can delegate the HR manager to internal management. You will have to manage it yourself.
  • the team master of each team also performs the digital signature of the membership, the management of the shared members in each team does not need to be interfered by the parent team. 86.
  • the team 103 m5 of team 103 ⁇ is digitally signed by Team Master X and cannot be managed by the parent team administrator. However, if the initial state of the sub-team when it is first created, or if the team master of the sub-team has been changed by the parent team's team master or sub-solarity, the digital signature of the authority list will be replaced by the sub-team's digital signature. It is a digital signature of the team master or subordinate of the parent team that created it.
  • the present embodiment is configured to separate the authority data and the authority list, and the parent team can refer to the authority data AUD ⁇ of the sub team, while the parent team can refer to the authority data AUD ⁇ of the sub team.
  • the authority confirmation function 35 ⁇ refers to the authority data 336 ⁇ ⁇ authority list 34 ⁇ from the client CLS side, When each change or deletion request is made, identify the requestor and determine whether to grant or deny these requests.
  • the list storage function 36 ⁇ is the authority confirmation function 35 ⁇ is the authority data 33 6 87-When using the list 34 ⁇ , take care of the process of acquiring these lists from the storage device 32 ⁇ , deleting them from the storage device 32 ⁇ , or storing them in the storage device 32 ⁇ . I have.
  • the list storage function 36 ⁇ must be interposed. However, it will not be explained one by one because it becomes complicated.
  • the list validity check function 37 ⁇ sequentially reads the parent team's authority list and authority data up to the root team, and finally In addition, the digital signature of Team Master No. 10 of Team 10 is checked to verify the validity of the authority list and the authority data. The legitimacy here means that the management of the team hierarchy is performed through a legitimate procedure without any tampering or over-rights act.
  • the AUD / AUL change function 38 ⁇ is added to the authority data 33 3 ⁇ authority list 34 4 ⁇ obtained by the list validity check function 37 ⁇ by adding members and administrators, In addition to making changes such as deletions and substitutions, when creating a sub-team, etc., new authority data 33 3 and an authority list 34 4 ⁇ may be newly created.
  • the digital signature function 3 9 ⁇ is a secret that only the changer can know about the authority data 3 3 ⁇ and the authority list 3 4 ⁇ processed by the AUD / AUL change function 3 8 6.
  • the digital signature of the creator or modifier of these lists ie, the team master or sub-authority
  • the public key management function 40 ⁇ accesses the public key database 41 ⁇ connected to the team data list management device 30 ⁇ , and Get the public key ID corresponding to the 88 key.
  • the public key database 41 ⁇ is not only in the oral form directly connected to the team data list management device 30 ⁇ , but also on the network such as the Internet.
  • the form that exists in the installed server for example, a certificate authority
  • the public key management function 40 ⁇ accesses the public key database 4 1 ⁇ via a homepage registered on the certificate authority, and from there the public key and public key ID described above are accessed. It can also be obtained in the form of a file.
  • the operation of the system having the team data list management device 300 and the team data list storage device 316 configured as described above will be described for each request made from the client CL ⁇ to the server SV 6. I will do it.
  • Figure 41 shows the procedure for creating a sub-team.
  • member C the sub-solarity of team 101 ⁇ shown in Fig. 40,
  • a sub-team 103 ⁇ with the team master as member X is created under the sub-unit 10 1 ⁇ .
  • This is equivalent to the case where a deputy general manager performs a task of establishing a new section under the human resources department on behalf of the human resources department.
  • the team data list storage device 31 ⁇ a team data list for the team 101 ⁇ created according to a valid procedure is stored in the storage device 326 in advance, and the root team 101 ⁇ Sub-teams are created using the management system of Team Master II.
  • a fixed value “Root 0” is set for the parent team ID of authority data 101 d ⁇ .
  • the team data list management device 303 sends a sub-team creation request to the team data list storage device 31 ⁇ (step S111 ⁇ ).
  • the team data list storage device 3 1 ⁇ acquires the authority data 10 1 d ⁇ and the authority list 10 1 u ⁇ from the storage device 3 2 ⁇ and stores them in the team data list management device 3. Send to 0 ⁇ .
  • the team data list storage device 31 ⁇ also includes the team data list for the sub-teams (ie, the team 102 ⁇ shown in Fig. 40) if there are sub-teams under the team 106.
  • the data is sent to the team data list management device 30 ⁇ (step S 12 ⁇ ).
  • the AUD / AUL change function 38 ⁇ changes the parent team ID to the team 1010 and the team ID to the team 10 3 based on the instruction from the member C ⁇ .
  • Authority data 103 d ⁇ with ⁇ and the team master as member X is created, and a authority list 103 ua ⁇ with the team master as member X is created.
  • the AUD / AUL change function 38 ⁇ passes the created authority list 103 ua S together with the authority data 103 d ⁇ to the digital signature function 39 ⁇ .
  • the digital signature function 39 ⁇ obtains the secret key for member C from the secret key file or the IC card in which the secret key is recorded, and based on this, sends the key sent from the AUD / AUL change function 38 ⁇ .
  • the digital signature of member C, the requester is applied to the solicited data 103 d ⁇ and the authority list 103 ua0. 90 Do it.
  • the digital signature of the authority list 103 ua0 is not the one of Team Master X, but the digital signature of the creator of the sub-team (above, step S 13 ⁇ ;).
  • the digital signature function 39 ⁇ stores the authority data 103 d ⁇ and the authority list 103 ua S created for the team 103 ⁇ in the team data list storage device 31.
  • the request is sent to ⁇ to make these storage requests (step S 14 S).
  • the authority confirmation function 35 ⁇ confirms the authority shown in the flowchart of FIG.
  • the authority confirmation function 35 ⁇ identifies that the requester who made the storage request is the member C (step S 3 1 ⁇ ), and the authority data 1 0 1 d ⁇ for the team 10 1 ⁇ Then, it is determined whether or not the member C is a team master or a sub-solarity of the team 101 ⁇ ⁇ based on the authority list ⁇ ⁇ ⁇ ⁇ ⁇ (step S32 ⁇ ). In this case, since the member c is a sub-authority of the team 101 ⁇ , a request to save the data created by a person with the right authority is made and the judgment is made (the judgment result of the step is “YE S”).
  • the authority confirmation function 35 ⁇ is the requester both with the created sub-team 103 ⁇ 's solidity data 103 d ⁇ and the digital signature of the authority list 103 ua 0 Confirm that it belongs to member C (step S33 ⁇ ).
  • the judgment result in this step is “YES”, and the authority confirmation function 35 ⁇ indicates that the sub team was created with normal authority.
  • step S 3 4 S the storage device 3 2 ⁇
  • the authority check function 35 5 stops the processing without performing the required saving operation
  • the creation of the sub team is completed.
  • a member X who is the team master of the team 103 ⁇ has made a management request to the team, such as setting information sharing members and sub-team creation authority.
  • a management request to the team, such as setting information sharing members and sub-team creation authority.
  • the team data list management device 30 ⁇ based on the management request instructed by the member X, adds the team data list relating to the parent team 103 ⁇ to the team data list.
  • Require storage device 3 1 ⁇ (step S 16 S).
  • the team data list storage device 3 1 ⁇ is based on the request contents, and the sub-team 103 ⁇ and all parent teams up to the root team (in this case, the root team 10 1)
  • the team data list relating to ( ⁇ only) is transferred to the team data list management device 300 side (step S17 ⁇ ).
  • the list validity check function 37 ⁇ checks the validity of the transferred list according to the processing procedure shown in the flowchart of FIG. 7 (step S1).
  • the list validity confirmation function 3 7 ⁇ is the originality data of the team 10 3 ⁇ to be managed 10 3 d ⁇ and the digitality of the authority list 10 3 ua S Referring to the signatures, it is checked whether they have been tampered with (step S41 ⁇ ). 92. Cancel the processing to be performed (the judgment result of the step is “NO”) c—If the judgment result of the step is “YES” and there is no tampering, the list validity confirmation function 37 ⁇ From the authority data 103 d ⁇ , it can be confirmed that the member X is the team master of the team 103 ⁇ .
  • the list validity check function 37 ⁇ confirms from the authority list 103 ua S that the digital signer is the member X who is the team master. However, as described above, this is a transition period in the process of creating a sub-team, and the digital signature of the authority list 103 ua 5 is the member C ⁇ who is the sub-team creator. Whether member C has a legitimate right to create a sub-team is determined by member C as a team master or sub-authority of parent team 101 ⁇ in the process described below (step S45 ⁇ ). It is confirmed by checking whether it has been performed (step S 4 2 ⁇ ).
  • the list validity check function 37 ⁇ knows that the parent team is team 101 ⁇ from the parent team ID of the originality data 103 d ⁇ (step S 43 ⁇ ), and the parent team Check whether the digital signatures of the originality data 101 d ⁇ and the authority list 101 u ⁇ have been tampered with (Step S440) c. If this is the case, the list validity confirmation function 3776 stops the processing (the judgment result of the step is "NO”); and the judgment result of the step is "YES”. If there is no tampering, it is confirmed whether or not the creator of the team 103 ⁇ is the team master or the sub-solarity of the parent team (step S45 ⁇ ).
  • the digital signer of the authority data 103 d ⁇ of team 103 ⁇ is member C, and the authority list 101 0 ⁇ of the parent team 101 ⁇ is assigned to member C.
  • the authority list 101 0 ⁇ of the parent team 101 ⁇ has valid creation authority 93-It can be confirmed that it was created by the person (the judgment result of the step is "YES"). If the result of the determination in this step is "NO”, the list validity confirmation function 3776 stops processing assuming that an illegal act has occurred.
  • the list validity check function 37 ⁇ checks whether the parent team 101 ⁇ is the root.In this case, the authority data of team 101 ⁇ is the parent team of 101 d ⁇ .
  • the list validity check function 37 ⁇ examines the authority data 101 d ⁇ of the team 101 ⁇ and finds that the team master is a member ⁇ . Since the authority data 101 d ⁇ and the authority list 101 U0 are digitally signed by this member A, it is confirmed that the team hierarchy is properly managed under the team master ⁇ . Yes (step S47 ⁇ ). Finally, the member X itself operates the team data list management device 306, and under the team hierarchy managed by the team master ⁇ of the root team 101 ⁇ , a team data list such as information sharing is provided. Approve that the use of the site or the use of the hierarchical team is performed, and notify the list validity confirmation function 37 ⁇ of this.
  • the list validity check function 37 ⁇ has been created by the sub-authority C designated by the team master ⁇ of the team 101 ⁇ and has created the authority data and the authority list for the team 103 ⁇ . It can be confirmed that these team data lists have been acquired in a normal state from the team data list storage device 31 ⁇ . Therefore, the list validity check function 37 ⁇ passes the team data list transferred from the team data list storage device 316 to the AUD. AUL change function 38 ⁇ . Note that step S 4 6 ⁇ in FIG.
  • the list validity check function 3 7 Changes the target team to the parent team and moves up the team hierarchy one step toward the root team (step S496), and the parent team becomes team 101 ⁇ as the root team (step S49).
  • the loop consisting of steps S42S to S46S and step S49 ⁇ is repeatedly executed until the determination result of S46 ⁇ is "YES”.
  • the AUD / AUL change function 38 ⁇ is the authority list 1 that adds members W and members V as sub-solars to the team 103's authority list 103 ua0.
  • step S 196 this is transferred to the team data list storage device 31 ⁇ together with the authority data 103 d ⁇ , and a storage request for these team data lists is made (step S 196). 2 0 ⁇ ).
  • the authority confirmation function 3 5 ⁇ is used in response to a storage request from the team data list management device 3 0 ⁇ , the team 10 0 stored in the storage device 3 2 ⁇ . Based on the team data list relating to 1 ⁇ and the team data list relating to 103 ⁇ transferred from the client side, the authority confirmation shown in the flowchart of FIG. 44 is performed. That is, first, the authority confirmation function 35 ⁇ identifies that the requester who instructed the storage request is the member X (step S510), and transferred the transferred authority data 1. 95-
  • the requester determines whether the team master of the team 103 ⁇ , the team master of the parent team 101 1 ⁇ , or the sub-solarity To see if any of them match.
  • the requester member X has been registered as the team master of team 103 ⁇ (the judgment result in step S5262 is “YE S”), so the authority confirmation function 35 ⁇ is required. Determine that the user has the right to the storage request. By the way, if the judgment result of this step is "NO”, the authority confirmation function 35 ⁇ stops processing assuming that the requester has not been given valid authority.
  • the authority check function 35 ⁇ checks whether the digital signer of the authority data 103d ⁇ matches the parent team's team master or sub-authority.
  • the digital signer of the authority data 103 d 0 is member c and a sub-authority of the parent team 101 ⁇
  • step S53 ⁇ determines that the requester has valid authority for the storage request. By the way, if the judgment result of the step is "NO”, the authority confirmation function 35 ⁇ stops processing as if there is a revision or an illegal act.
  • the authority confirmation function 35 ⁇ confirms whether the digital signer of the authority list 103u6 matches the team master registered in the authority data 103d ⁇ . In this case, the digital signer of the authority list 103 u ⁇ is the team master X indicated by the authority data 103 d ((judgment result of step S 5 4 ⁇ is “YE S”).
  • Step S5 5S Update the contents of step 96 (Step S5 5S) C If the judgment result of Step S54 4 ⁇ is “NO”, the authority confirmation function 35 5 ⁇ is regarded as having been tampered or fraudulent. The processing is stopped, and the storage processing in step S55 ⁇ described above is not performed. As described above, based on the team data list stored on the server SV ⁇ side, the member X is ideally the legitimate team 103 ⁇ in the management system of the root team team master ⁇ . It can be verified that he has been appointed as the team master (step S21 ⁇ in Fig. 41).
  • a member ⁇ registered as a sub-authority in the root team 101 ⁇ changes the team master of team 103 ⁇ which is a sub-team from member X to member ⁇ .
  • the team data list management device 30 ⁇ sends a change request for the team data list relating to the sub team 1030 to the team data list storage device 316 (step S61 ⁇ ).
  • the team data list storage device 3 1 ⁇ is the same as the step s 1 2 ⁇ in FIG.
  • Step S62 ⁇ Transfer the data list to the team data list management device 30 ⁇ side (Step S62 ⁇ ).
  • the list validity check function 37d is transferred to the team data list according to the processing procedure described in Fig. 43. 97 is verified (step S636), and if the validity is verified, the transferred team data list is passed to the AUD / AUL change function 38 ⁇ .
  • AUD / AUL change function 3 8 ⁇ changes the team master from member X to member ⁇ ⁇ ⁇ ⁇ for authority data 103 d ⁇ in the delivered team data list according to the instruction from member ⁇ , and makes this change.
  • the obtained authority data and the passed authority list are sent to the digital signature function 39 ⁇ .
  • the digital signature function 39 9 ⁇ obtains the private key for member ⁇ ⁇ from the above-mentioned private key file, etc., and applies a digital signature to the team data list sent, so that the authority data 103 db After the ⁇ and the authority list 103ub6 are created (step S646), these team data lists are transferred to the team data list storage device 31 ⁇ to make a storage request (step S64). S65 ⁇ ) 0 In the team data list storage device 316, based on the team data list to which the authority confirmation function 35 ⁇ was transferred, the authority is confirmed according to the procedure shown in Fig. 44. When the validity is confirmed, the transferred team data list is stored in the storage device 32 ⁇ .
  • the difference from the sub-team creation step S21S in Fig.
  • the teams involved in the team 103 ⁇ 98 As a data list, two sets of authority lists with different creation times and authority data, that is, each team data list before and after the change of the team master are stored.
  • the team data list storage device 31 ⁇ gives the digital signature of the member ⁇ who is the new team master of team 103 ⁇ to the authority list 103ub ⁇ in order to give it a digital signature.
  • the solitary data 103 db ⁇ and the solitary list 103ub5 are transferred to the team data list management device 30 ⁇ (step S66 ⁇ ).
  • the list validity check function 37 ⁇ verifies the validity of the transferred team data list according to the processing procedure in FIG.
  • the digital signature function 39 ⁇ obtains a secret key for member ⁇ ⁇ from the above-mentioned secret key file and the like, and performs a digital signature of member Z on the authority list 103 ub 5 based on this.
  • a solitary list 103 ucS is created (step S67 ⁇ ).
  • the digital signature function 396 transfers the created authority list 103 uc5 to the team data list storage device 31 ⁇ together with the authority data 103db ⁇ (step S68 ⁇ ). .
  • the team data list storage device 316 checks the authority according to the processing procedure shown in Fig.
  • the obtained team data list is stored in the storage device 326, and the team data list relating to the team 103 ⁇ is updated. This means that the Team Master has been changed following the normal procedure.
  • Fig. 46 for the processing procedure for changing the sub-solarity.
  • the team master ⁇ ⁇ power of the team 101 ⁇ which is the root; and the case where the authority to create a member ⁇ ⁇ ⁇ ⁇ registered as a sub-authority by this team 101 ⁇ is Will be described as an example.
  • the team 103 ⁇ whose sub-authority ⁇ is the creator due to the change of the team master shown in Fig. 45 is assumed.
  • the figure also shows two cases, one in which team 1303 is deleted as the authority to create sub-authority ⁇ is deleted, and the other in which team 1303 is continued. Is shown. Therefore, when the member ⁇ instructs the request to the team data list management device 306, it also instructs whether to keep the team 103 ⁇ .
  • the team data list management device 30 ⁇ sends a change request (deletion request) to the sub authority ⁇ registered in the team 101 ⁇ to the team data list storage device 31 ⁇ (step S 7 10): Accordingly, the team data list storage device 3 1 ⁇ refers to the authority data of the sub-teams under the team 101 ⁇ and selects the sub-team ⁇ ⁇ ⁇ After searching for the team 103 ⁇ for which the creator is the creator, the team data list for the team ⁇ ⁇ ⁇ ⁇ and team ⁇ 0 3 ⁇ is transferred to the team data list management device 30 ⁇ (step S720). In the team data list management device 30 ⁇ , the list validity checking function 37 ⁇ checks the validity of the transferred team data list according to the processing procedure described in FIG. If the team data is verified, the team data list transferred to the AUD / AUL change function 388 is passed. 100
  • AUL change function 3 8 ⁇ is a member from the sub-authorities described in the originality list ⁇ ⁇ ⁇ ⁇ ⁇ in the team data list delivered based on the instruction content from member ⁇ ⁇ ⁇ .
  • a solution list l Olub S from which ⁇ has been deleted is created (step S73 ⁇ ).
  • the AUD / AUL change function 3 8 ⁇ deletes the digital signature of the member ⁇ added to the authority data 103 db ⁇ to create the authority data 103 dc ⁇ (step S 74 S).
  • the AUD 'AUL change function 38 ⁇ sends the authority data 103 dc ⁇ and the authority list 103 uc ⁇ to the digital signature function 396.
  • Digital signature function 39 9 performs one of the following two processes according to the instruction from member ⁇ . First, if there is a request to continue Team 103 ⁇ , the digital signature function 39 ⁇ considers that the existence of Team 103 ⁇ has been approved by the member ⁇ The secret key for member A is obtained from the above, and based on this, the digital signature of member ⁇ ⁇ is attached to the authority data 103 dc ⁇ to create the authority data 103 dd ⁇ (step S75) 0). Next, the digital signature function 39 ⁇ transfers the authority data 10 1 (1 ⁇ , 103 dd ⁇ and the authority list l Olub ⁇ , 103 uc S to the team data list storage device 31 ⁇ .
  • a request is made to save the team data list (step S760)
  • the authority confirmation function 35 ⁇ is based on the transferred team data list.
  • the authority is confirmed according to the procedure shown in FIG. 44, and when the validity is confirmed, the content of the storage device 320 is updated with the transferred team data list (step S77) S)
  • 101 Digital signature function 3 9 ⁇ is a team data list storage device for team 10 1 ⁇ , that is, authority data 10 1 d ⁇ and authority list l Olub ⁇ .
  • an instruction to invalidate the team 103 ⁇ is sent to the team data list storage device 31 ⁇ (step S78 ⁇ ).
  • the authority confirmation function 3 5 6 matches the authority list 1 0 1 u 6 stored in the storage device 3 2 ⁇ with the sent authority list l Olub S By doing so, the deletion of sub-authority B can be recognized.
  • the authority confirmation function 35 ⁇ is based on the contents of the authority data 101 d ⁇ and the authority list 101 ub ⁇ , and the team master is a member ⁇ and these team data lists are It can be seen that all members are digitally signed by this member A.
  • the authority confirmation function 35 ⁇ determines that the team master ⁇ has deleted the sub-authority B ⁇ with valid authority, and the authority data 101 d ⁇ and the authority list l Olub S The team data list of the team 100 in the storage device 3 2 ⁇ is updated with the contents of the above.
  • the authority confirmation function 35 ⁇ deletes the authority data and the authority list relating to the team 103 ⁇ from the storage device 32 ⁇ (above, step S79 ⁇ ). As described above, the authority to create sub authority ⁇ has been deleted from the team data list on server SV ⁇ .
  • the team data list management device 30 ⁇ notifies the team data list storage device 31 ⁇ of the digital signature of the member C as described later.
  • the team data list management device 30 ⁇ becomes a member by the digital signature function 39 ⁇ .
  • a command to delete team 103 ⁇ with the authority of member C and the digital signature of member C are combined and transferred to the team data list storage device 31 ⁇ .
  • S 8 1 ⁇ As a method other than attaching a digital signature, a method called “shake hand” or “challenge response J” (details will be described later) that certifies at the time of transfer of the deletion instruction may be adopted.
  • the shake hand will be described as an explanation in accordance with the method using a digital signature:
  • the team data list storage device 3 1 ⁇ is converted from the team data list management device 3 0 ⁇ to the team 10 3 ⁇
  • the authority confirmation function 3 5 ⁇ is received
  • the authority confirmation function 35 ⁇ compares the digital signature of member C described in the authority data 103d ⁇ with the digital signature of member C attached to the deletion instruction, and if these match, Being By confirming with 103, it is possible to confirm that the person who ordered the deletion is definitely Member C himself. In this way, the authority confirmation function 35 ⁇ is determined to be a delete instruction issued with a proper authority, and the authority data 10 3 d ⁇ and the authority 10 The list 103 u ⁇ is deleted (step S820).
  • the authority confirmation function 3 5 ⁇ refers to the team data list for team 10 10 and team 10
  • the sub-authority C registered in ⁇ is the creator of Team 103 ⁇ , and this sub-solarity C has been designated as the sub-authority by the team master ⁇ of the parent team 110 It turns out that it is.
  • the authority confirmation function 356 is deleted by comparing the digital signature of member ⁇ described in the authority data 101 d ⁇ with the digital signature of member A attached to the deletion instruction. Confirm that the person who instructed is definitely Member A himself. In this way, the authority confirmation function 35 ⁇ determines that this is a delete instruction issued with valid authority, and from the storage device 32 ⁇ , the solution for the team 103 ⁇ is determined.
  • step S 84 ⁇ The team master A completes the deletion process of the team 103 ⁇ by c or more. It will be done. In addition to the members described above, for example, it is also possible to delete the team 103 ⁇ in which the member ⁇ registered as a sub-authority in the team 101 ⁇ is a sub-team. Lastly, the details of the above-described shake hand or challenge response processing procedure will be described with reference to FIG. First, when accessing the server SV ⁇ , the client CLS sends the user name (user C or member ⁇ in FIG. 47) and the user public key to the server SV ⁇ (step S 1). 0 1 0).
  • the server SV 0 generates a random number, stores it internally, encrypts the random number with a user public key (step S 102 ⁇ ), and transmits the encrypted data to the client CLS as “challenge data”.
  • the client CL ⁇ decrypts the challenge data sent from the server SV ⁇ with a secret key corresponding to the user public key (step S104 ⁇ ), and converts the obtained decrypted data into a “challenge response”. Is returned to the server SV ⁇ (step S 1 050).
  • the server S ⁇ compares the challenge response sent from the client CL6 with the random number generated in step S102 ⁇ to confirm the communication partner.
  • step s101 ⁇ it is possible to confirm that the person who knows the secret key corresponding to the user public key sent in step s101 ⁇ is the communication partner (successful authentication). On the other hand, if the two do not match, it is known that the communication partner may not be a person with valid authority (authentication failure) (step s106 ⁇ above).
  • the server s V ⁇ is the same as the one obtained in step S 106 ⁇ .
  • 105 Notify the authentication result (authentication success or authentication failure) to the client CL ⁇ (step S107 ⁇ ).
  • the server SV ⁇ can confirm that the member C ⁇ member ⁇ is the same person as in the case where the digital signature is attached.
  • the “user public key number” may be sent.
  • the user public key number referred to here is information for identifying and authenticating the user himself / herself, and is a serial number assigned in advance to each user public key. More specifically, the user public key number is information corresponding to each user public key for uniquely identifying the user public key. For example, the user public key number is included in the certificate issued by the above-mentioned certificate authority. This is the serial number of the certificate.
  • various information such as an ID and a name for actually identifying the key creator himself / herself can be used in addition to the user public key number just described.
  • FIG. 49 illustrates the layering of teams according to the present embodiment, in which applications that can be used by members of the team are different for each team.
  • the authority list and authority data are the same as those shown in Fig. 40.
  • each team has an application list that includes the contents of the member list instead of the member list. , 102 a6 and 103 a ⁇ are provided.
  • these application lists include, in addition to the systems available to members belonging to each team, 106 lists are listed.
  • a personnel management system, an accounting system, a schedule, and a file sharing system are registered in the application list 101 a ⁇ of the team 101 ⁇ .
  • the member list is the same as that described in the member list in FIG.
  • the team generation is subject to the interference of the parent team, but the application list is digitally signed by the team master of each team. Therefore, management within the team can be performed without interference from the parent team.
  • the members who can share applications that can be used in the team can be determined independently by the parent team administrator by the team master.
  • the digital signature of application list 102 a S is the digital signature of member ⁇ ⁇
  • management authority sharing within a team for sharing information is performed. Men who belong to the team, sub, master
  • the submaster is an administrator in the team designated by the team master, and is not allowed to change the teammaster / submaster.
  • the submaster can add, delete, and change general members.
  • the team master He is the one who can change the data or the members, and even his own team master.
  • general members other than the submaster and the team master are those who share the information and functions provided to the members, and have no authority to make changes to the contents of the team data list.
  • the submaster and the team master are given special authority, they are still members within the team, and in that sense, the submaster or team master is sometimes called a member.
  • FIG. 50 shows the hierarchy of teams in the present embodiment.
  • a team master list is further added to each team of the 4-1 embodiment shown in FIG. In this way, information sharing is managed for each team, and multiple administrators can manage the information sharing members in each team.
  • FIG. 50 a list of team masters and submasters registered in each team and a digital signature of the team master are described in a team master list 101 t ⁇ to 104 t ⁇ .
  • the team master list includes the identification information of the team master or submaster, the public key, the public key ID, the team ID, and the time stamp indicating the time when the team master list was created.
  • the team master list 34 ⁇ includes information on the team, such as the number of team members, the time when the team was created, and various functions that can be used by each member in the team (for example, the above-mentioned information).
  • Application list which can be used to manage information resources for each team at the same time.
  • the digital signature of the team master list is digitally signed by the team master of each team at the time of team creation, and thereafter, it is digitally signed by the team master.
  • the submaster has been given the authority to manage the member list. Therefore, in addition to the team master, the submaster may be digitally signed.
  • the digital signature of the member ⁇ registered as a submaster of the team 101 ⁇ is made.
  • the member list 102 ma Will sign.
  • sub-team management authority and member management authority are divided into authority list / authority data and team master list, so different persons are assigned to sub-authority and sub-master in each team. You can guess.
  • members W and V are sub-authorities
  • members ⁇ and ⁇ are sub-masters.Therefore, different persons may be in charge of sub-team management and member management to balance the load. it can.
  • the sub-authority and the sub-master can be the same member, and in that case, it is possible to combine the authority list and the member list into one list.
  • each time the team data list is used the user needs to confirm on the client CL ⁇ whether the team master is definitely his or her own team master.
  • the user needs to confirm on the client CL ⁇ whether the team master is definitely his or her own team master.
  • This list is normally managed by the following members as an administrator. Name: Member ⁇ . Organization: Mitsubishi Materials Click the ⁇ ⁇ button to continue working. Click here for a message. "In this way, it is necessary for the user to visually confirm the message, and there is no possibility that the user will have a troublesome impression.
  • the following functions are added as new functions linked with the list validity check function 37 ⁇ , or as a function of the list validity check function 37 ⁇
  • the public key of the team master in the root team 101 ⁇ is previously set for each team, for example, the public key database 41 ⁇ on the client CL ⁇ side (see Fig. 37).
  • the public key management function 40 ⁇ obtains the public key of the team master of team 1 ⁇ 1 ⁇ ⁇ from the public key database 410 and lists it. to ⁇
  • a serial number for identifying the public key is registered as information relating to the public key, and the public key management function 4 06 discloses this serial number.
  • the public key registered outside the team data list management device 300 (for example, on the Internet) is separately obtained based on this, and the list validity is confirmed.
  • the function may be passed to the function 37 ⁇ .
  • the list validity checking function 37 ⁇ is not transmitted from the public key management function 40 ⁇ instead of outputting the above-mentioned message on the computer display.
  • the team master's public key of the notified team 100 1 ⁇ the team data contained in the authority data 100 1 d ⁇ transferred from the team data storage device 3 1 ⁇ So as to verify the digital signature, the digital signature shall determine whether those teams master is registered. In this way, the user is visually confirmed based on the display on the display 110, it is possible to verify the validity of the team master of the root team 101 ⁇ .
  • the team data list management program for managing the team data list for hierarchizing the teams, the team data list management program: (1) A process for requesting an operation of the data list; and (2) an identifier indicating the parent team of the own team and an administrator of the parent team for each team from the operation target team to the root team in response to the operation request.
  • Data containing the digital signature of the team, manager information on the management authority of the sub-team under the control of the team, and the team master who is the manager of the team or the manager of the parent team A process of obtaining a team data list having the authority list including the digital signature of the request from the request destination;
  • the digital signature of the team data list has not been tampered with, and the digital signature has been obtained by an authorized person using the manager information for each team, while obtaining each team up to the root team. And then confirming the user's approval of the team master of the root team.
  • the operation is performed on the team data list whose validity has been confirmed by the validity confirmation process.
  • the confirmation process includes one or more sub-authorities designated by the team master from members of the own team and having the authority to manage the sub-team, and the sub-authority May be used as the manager information.
  • the above-mentioned team data list management program includes: a process of acquiring identification information for identifying a team master of the root team from a predetermined place and registering the identification information in advance; A process of confirming that the digital signature of the team data is the digital signature of the team master using the identification information registered in advance each time team team data is sent; May be further executed by a computer.
  • the team data list storage program includes: (1) an identifier indicating a parent team of the own team; The process of storing in advance the authority data containing the digital signature of the parent team administrator for each team
  • the administrator information is used to indicate that the digital signature of the team data list sent from the request source is a digital signature by an authorized person. After the confirmation, the computer executes the authority data stored in the transmitted team data list and the authority confirmation processing for updating the stored authority list.
  • the authority confirmation processing may be performed by one or more sub-solars who are designated by the team master from members of their own team and have the authority to manage the sub-team. And information on the team master having the authority to manage the sub authority in addition to the authority of the sub authority may be used as the administrator information.
  • the inventions of the fourth to fourth embodiments have the following effects.
  • a sub team can be created under each team by using the team data list including the authority list and the authority data, and a hierarchical team can be constructed.
  • the user can confirm the validity of the team data list for each team from the operation target team to the root team only by checking the digital signature of the team master of the root team.
  • anyone can become the team master who manages the sub-teams under the direction of the parent team manager.
  • the team data list is divided into the authority data under the management of the parent team and the authority list relating to the management of the own team, and the team master of each team is divided into the parent team. Management within the team, such as management of information sharing members, without interference from the parent. 1 13 Team managers no longer need to be involved in sub-team internal management.
  • the present invention since a digital signature by a person having a legitimate authority is included in the team data list, it is possible to detect an illegal act such as falsification. Also, in the present invention, when an operation request for a team data list is made, the authority of the requester is checked to determine whether or not the person has the authority. It is possible to prevent unauthorized acts by members who do not have authority such as cracking power. In addition, in the present invention, sub-team management authority is given to the selected team master and one or more sub-solarities, and the team master itself can appoint a sub-solarity. The management burden is distributed because the team can be managed.
  • identification information for identifying and authenticating the team master of the root team such as a public key is registered in advance, and the team master of the root team is confirmed based on the identification information. This eliminates the need for the user to visually confirm each time he or she operates the team data list, and automatically approves the team master of the knowledge team.
  • the invention of the embodiments 5 to 6 d is in the field of broadcast communication using a computer network, and is capable of preventing improper operation by an administrator of an information relay device used for broadcast communication. About.
  • Broadcast communication refers to communication intended to transmit the same information to many terminals on a communication network at once.For example, in the case of an e-mail system, broadcast is performed by using a mailing list. Broadcasting is realized. Another example of broadcast communication is a real-time chat. In a general example of a broadcast system currently implemented, a transmitting terminal manages a set of recipients (receivers) (distribution destination list) for messages to be broadcast. Transfer to the information relay device.
  • Broadcasting is realized by copying the message distributed by the information relay device for the number of recipients and transferring it to each recipient of the broadcast.
  • a message is sent to a mailing list management host (Server A) that manages a mailing list (ListOl) indicating a set of recipients.
  • Server A a mailing list management host
  • ListOl mailing list
  • Ringurisu preparative manage each recipient phosphite I are listed in the mailing list (U ser a, U ser B s U ser C) message against
  • an encryption key is generated based on a data key used for encryption, destination information for specifying a recipient, and a master key common to the system, and the destination information and the encryption key are transmitted between the communication parties. It discloses an encrypted communication system that can share a data key with any one or more communication partners by transmitting and receiving data.
  • An encrypted information relay device in this broadcast communication system transmits and receives information from an originating subscriber in a system for transmitting and receiving information between a plurality of subscribers connected by a communication line.
  • a cryptographic calculation unit that decrypts the encrypted information (2) or encrypts the information sent to the receiving subscriber (3); a common secret key for decrypting the encrypted information;
  • a key storage unit storing an individual public key for each subscriber for performing encryption corresponding to (User A, User B, User C). 1 16
  • the administrator of this information relay device or the person who has been delegated authority by this administrator, will not be able to transmit the contents of encrypted communication, even if it is not included among broadcast subscribers. You can see him.
  • confidential information in broadcasts between companies includes merger information of companies, which is information that should not be leaked to the administrator of the information relay device affected by the merger.
  • the information relay device always performs the decryption processing and the encryption processing of the encrypted information.
  • encryption and decryption are complex and require large processing power. Therefore, if a large amount of encrypted information arrives at the information relay device at the same time, there is a danger that the broadcast will be delayed or the information relay device will exceed its processing capacity, resulting in inoperability.
  • the following problems were solved. The system needs to be realized.
  • the communication contents of the broadcast encryption communication realize a mechanism that cannot be seen by the clerk, and the contents of the broadcast communication can be viewed only by members who really need to share the information.
  • the distribution members are managed among the members performing the broadcast communication, and the administrative burden concentrated on the single member administrator is reduced as much as possible. I do.
  • the invention of the fifth to fifth embodiments is described as follows.
  • the invention of the fifth to fifth embodiments is described as follows.
  • FIG. 52 shows an outline of the broadcast communication system of the present invention. The embodiments of each device constituting the broadcast communication system of the present invention will be described later in detail.
  • the setting of the member to be delivered (recipient) stored in the information relay device (server) is mainly delegated authority by the server administrator or the server administrator. Was controlled by those who were.
  • a list of members to be distributed (hereinafter, referred to as a member list) is not a server administrator, but an administrator who manages members within a broadcast member (hereinafter, referred to as a team master). ) Management, this member 118 Provide a mechanism to prevent the list from being tampered with by others. Then, the member list is safely and securely shared among the members included in the member list, and the information content of the broadcast transmitted by the member is encrypted, so that the information can be leaked without leaking the information. It enables safe and secure reception of confidential information.
  • a mechanism is needed to identify and authenticate the communicating member.
  • a mechanism is used in which a private key in a public key cryptosystem (for example, an RSA (Rivest-Shamir-Adleman) method or an elliptical sign method) is owned only by the person. I do. Therefore, the member list of the present invention includes at least the public key corresponding to the private key.
  • a digital signature by the team master shall be attached to ensure that the member list is securely managed and a mechanism that is not falsified by others.
  • the member list is generally managed by the team master.For example, if the number of broadcast members is large and cannot be managed by a single administrator, the member list is managed. It may be divided into multiple lists and managed by multiple administrators (one team master and one submaster authorized by the team master) included in one team master list. As shown in Fig. 53, a general list of members is composed of the team name, the name or identifier of member X, which is the team master, and the members Y,. The member's name or identifier and the Team Master X digital signature for this member list.
  • the member list consists of multiple lists as described above, in particular, the member list is registered as the team master and the team 1 0 1 ⁇
  • An example is shown in which 119 broadcast members are divided into registered member lists.
  • the validity of the digital signature of the member list can be confirmed not only by the X of the team master but also by the digital signatures of ⁇ and ⁇ of the submaster.
  • the member list is verified for tampering, and the digital signer (in this example, member X) is specified.
  • the member list may be such that a plurality of public keys are registered for one member. For example, if a public / private key pair used for encryption / decryption processing and a public key / private key pair used for digital signature creation / verification processing use different key pairs, respectively. Therefore, two public keys are registered for each member. Also, a public key is registered in the member list. Digital certificates issued by 120 stations (for example, digital certificates conforming to the X.509 format, hereinafter referred to as certificates) can be used. Alternatively, a method of registering information for uniquely identifying the public key body in the member list may be used.
  • each member already has a public key body, information identifying the public key (for example, the public key included in a certificate issued by a trusted certificate authority is used.
  • the member list includes the serial No given to the certificate, the name of the certificate authority, and a message digest obtained by compressing the certificate with a hash function), each member will be a member After receiving the list, you can select or obtain the actual public key itself to be used for encryption. For example, if the member list includes the certificate authority name and serial No, the certificate authority name and serial number are first obtained from a plurality of certificates stored in a storage medium connected to the terminal.
  • FIG. 55 includes and illustrates the 5-1a to 5-1a embodiments of the member list management device of the present invention.
  • a list creation unit 1a a for creating a member list including a public key of one or more members performing broadcast communication, and a member list
  • the public key management unit 1 b £ acquires and stores the public key to be included.
  • the team master 1 enters predetermined items (member information, etc.) for creating a member list using the member list management device 1f.
  • the list creation unit 1a ⁇ selects the public key of the member to be registered as a member (step S1 ⁇ ). For example, when creating the member list shown in Fig.
  • the public keys of members X, ⁇ , ⁇ , ⁇ are selected.
  • a message digest of the member list is created using a hash function (for example, MD5 SHA-1) (step S 2 £ ).
  • encrypts the message one Jidaijiesu you created with the private key Ji one beam master e.g., by using the RSA or DSA
  • attach a digital signature created in the main Nbari be sampled (Step S 3 epsilon; 2 In the example, the digital signature of X is attached).
  • member one list management apparatus 1 "This embodiment of the 5 _ 1 a, further list acquisition storage unit 1 ct The configuration with is provided.
  • 122 list acquisition storage unit 1 c f is not only operative to perform acquisition storage member list for the connected storage medium member list management unit 1 f
  • member list management device 1 f is connected It uses terminals (eg, servers) and databases (not shown) located in the network to access these terminals and databases, and operates to acquire or save member lists.
  • This configuration is used because if one team master manages the member list and one terminal of the team master fails, the member list may be deleted accidentally. However, it is more secure to store the member list in a secure terminal (for example, a server) or database on the network instead of the terminal of the team master.
  • a secure terminal for example, a server
  • multiple members create a member list.
  • the broadcast communication system of the present invention prevents information from leaking outside the broadcast member by performing encryption using the public key included in the member list.
  • the member list management device 1f needs to verify whether the member list is managed with validity. Verification of legitimacy here means that 1) the member list is maintained without modification by unauthorized persons, and 2) the person who created the member list broadcasts. Qi It is the official team master of the system, to check the status.
  • the digital signature attached to the member list (in the example of FIG. 53, the digital signature of member X) is decrypted to obtain a message digest of the member list, and further,
  • the member list (in the example shown in Fig. 53, the list that has team 101 ⁇ , member X, member ⁇ ... member ⁇ ) is the same hash as the one used when creating the member list.
  • the message digest obtained by compression with the function is obtained, and verification can be performed by comparing the two.
  • the member list user can input the name of the digital signer to the member list (for example, the name described in a certificate that conforms to the X.509 certificate format).
  • the list acquisition and storage unit 1 cf is a function that creates and saves a correspondence table that associates information that identifies the member list with the team master that manages the member list, and is attached to the member list.
  • the member table is further equipped with a function to refer to this correspondence table and determine whether the digital signature is the digital signature of the valid team master. Can verify the validity of the
  • the member list user when creating the correspondence table, for example, in the case of the first member list to be acquired, display it on the screen so that the member list user can confirm the team master and have it confirmed Verify by If an affirmative instruction (when the team master is recognized as the digital signer of the member list) is issued, information identifying the member list (in the example of Fig. 53, “Team 10” in the team name) is output. 1 ⁇ ”) and a team master that manages the member list (in the example of Figure 53,“ member 1 ”is the team master). By adding an additional function to add 124 to the table, the validity is automatically checked from the second time on.
  • the function for verifying the validity of the member list described here is also provided in each of the later-described signal information creation device, encryption information decryption device, and information relay device. Works when using a member list.
  • the member list management device 1 ⁇ of the fifth-first a or the fifth-second a embodiment has a list.
  • the transmission unit 1 d f is further provided.
  • the list transmitting unit 1df operates to transmit a member list to terminals used by members included in the member list.
  • the latest member list can be quickly and accurately shared among the members of the member list.
  • the team master needs to change the distribution destination list referred to when the information relay device described later redistributes the information.
  • the mechanism for changing the distribution destination list differs depending on the type and mechanism of the information relay device. For example, the structure and protocol of the device differ between a voice communication system and an e-mail communication system.
  • the members included in the member list and the members included in the distribution destination list are set so that the operation method does not differ depending on the system to be used.
  • a function of changing the distribution destination list may be further added to the member list management device 1f so that the members become the same.
  • the simplest embodiment is the list transmission of this embodiment.
  • the member list is transferred from the 125d 1d E to the information relay device, and the information relay device uses this member list as a distribution list.
  • a member-list management device 1f of any one of the fifth-first to fifth-third embodiments is subscribed.
  • the request reception unit 1 e £ is further provided.
  • the subscription request receiving unit 1ef sets the items to be requested to join the specific broadcast distribution list in order for the broadcast team master to accept the request to subscribe to the broadcast member list.
  • the request function that sets the required items to be fulfilled, the function that presents the items to be satisfied by the requester when accepting the request, and the request transmitted by the requester satisfy the required items. It has a subscription permission determining function of determining whether to permit the subscription.
  • the subscription request receiving unit 1 e ⁇ of the present embodiment makes an inquiry to a database server or the like arranged on the network to check whether the subscription request is an accurate request. Perform verification. For example, if the credit card ⁇ is described in the enrollment item, the validity of the credit card ⁇ will be verified by accessing the terminal operated by the credit card company, or If the certificate is included, it can be verified by accessing the certificate database operated by the certificate authority.
  • the above-mentioned function of the subscription request receiving unit 1 e £ enables automatic recipient subscription to the broadcast communication.
  • the process of subscribing to a mailing list is automated, and when a user registers on a WWW page, it is automatically added to the mailing list.
  • the current mailing list automates the process that is started with the authority of the information relay device administrator, and in the current automation process, the information relay device administrator has free access to the distribution members. It only provides a mechanism that can be set to.
  • the subscription request receiving unit 1 e ⁇ is for preventing a fraud by an administrator of a malicious information relay device or the like, and for providing a more secure automatic subscription mechanism.
  • the public key and private key included in the member list are undoubtedly the power of their own, whether they have expired if the expiration date has been set, etc. It is better to use after verifying that there is no leakage. Therefore, in each embodiment of the member list management device 1f, a database (for example, a state that indicates the validity and reliability of a public key provided by a certificate authority / service company) is registered in the network.
  • SMTP Simple Mail Transfer Protocol
  • LDAP Lightweight Directory Access Protocol
  • CSP Online Certificate Status Protocol
  • CCL certificate revocation list
  • the function described here to verify the validity of the public key and the private key used for digital signature must be provided in each of the cryptographic information creation device, information relay device, and cryptographic information decryption device described later. This is effective for digital signature confirmation / member list management.
  • FIG. 57 includes and illustrates Embodiments 5-1b to 5-3b of the cryptographic information creation device of the present invention.
  • the 5-1b embodiment of the encryption information creation apparatus includes a list acquisition and storage unit 2af that acquires and saves a member list via a network, and an encryption unit that creates code information. 2 b ⁇ .
  • the list acquisition and storage unit 2a £ stores member lists stored in a resource database located on the network in the same or different protocol as broadcast (for example, by broadcast). When using SMTP, fetch using HTTP). Alternatively, the transferred member list is stored in a storage device (not shown), and obtained by reading the member list from the storage destination when necessary.
  • the list acquisition and storage unit 2a £ operates to check whether the member list is the latest version.
  • a database located on the network that stores information about the latest version of the member list may have the same or a different protocol (for example, when using SMTP for broadcast). Query the latest member list version using LDAP, OCSP, etc.).
  • the list acquisition and storage unit 2a ⁇ has a function of verifying the validity of the list described in the embodiment of the member list management device 1 ⁇ described above. Verify the validity of the list.
  • the storage unit (not shown) is configured by a nonvolatile storage device such as an EEPROM, a hard disk, and a magneto-optical disk.
  • the encryption unit 2b £ first obtains the broadcast message (plaintext) and the member list obtained by the list acquisition and storage unit 2a £, as shown in Fig. 58, and converts the broadcast message. Create a ciphertext by encrypting with a common key cryptosystem (for example, an encryption system that uses the same key for encryption and decryption such as DES).
  • a common key cryptosystem for example, an encryption system
  • an encryption key is created by encrypting the common key used to create the ciphertext using a public key encryption method (for example, the RSA method) using each member public key included in the member list. At this time, if there are three members, three encryption keys will be created.
  • a public key encryption method for example, the RSA method
  • key selection information for selecting an encryption key corresponding to the member to be distributed among a plurality of encryption keys is created.
  • this key selection information for example, a table that associates a member name with an encryption key may be used.
  • the broadcast message is compressed by a hash function, and a digital signature encrypted with the sender's private key is added. With this digital signature, falsification can be prevented and the sender can be confirmed.
  • the encryption information creation device 2 £ is used at the transmitting terminal.
  • the 5-2b embodiment of the cryptographic information creating device 2 £ has a configuration in which the 5-1b embodiment further includes a destination inspection unit 2 c £.
  • the 5-1b embodiment further includes a destination inspection unit 2 c £.
  • Destination check unit 2c ⁇ ⁇ checks the destination of the broadcast message, and if the information relay device is the destination and the list of members used for broadcast can be obtained, It operates to pass the broadcast message to the encryption unit 2 b b.
  • the encryption information creation device 2f can perform only the encryption process, and therefore, the creation of the broadcast message itself can be performed by a general-purpose message creation device (word processor, Mailers, chat clients, etc.).
  • a general-purpose message creation device word processor, Mailers, chat clients, etc.
  • the encryption information creation device 2 £ is implemented as a mailer's plug-in software
  • the functions of the existing mailer can be used up to the creation of the text and attachments of the mail.
  • the plug-in software as the cryptographic information creation device 2 E checks the destination before sending the mail, and if the destination is the address of the mailing list server, the member corresponding to this address A list is obtained, and the above-mentioned encryption is performed using the public key included in the member list to create encryption information.
  • This encrypted information is sent to the mailing list 'server using the communication function used by the existing mail (for example, the communication function using SMTP as a protocol).
  • the cryptographic information creating apparatus 2 of the present embodiment may further include a dedicated broadcast information creating unit (not shown) for creating a broadcast message.
  • the fifth-third embodiment of the cryptographic information creation device 2 £ is different from the fifth-first b or the fifth-second b embodiment in that the multi-part transmission unit 2 d ⁇ ⁇ ⁇ is further provided.
  • the encrypting unit 2 b f when the broadcast message is composed of a plurality of parts, performs the above-described encryption processing for each individual packet and performs encryption. 130 Create information. Then, as shown in FIG. 59, when the broadcast message is composed of a plurality of parts as shown in FIG. 59, the multi-part transmitting unit 2d ⁇ transmits some of the parts according to the receiving capability of the information relay apparatus. It operates so that it can be sent to the information storage device 5f that can be referenced from the relay device. At this time, the most suitable protocol for transmitting each part can be used. For example, use a real-time communication protocol for voice chat, and use a file transfer protocol for file transfer.
  • the multi-part transmission unit 2 df can refer to the information relay device 4 ⁇ ⁇ ⁇ ⁇ ⁇ by referring to the resource database or the information relay device 4 ⁇ arranged on the network, and can refer to a part of the broadcast message from the information relay device 4 £. Know the information storage device 5 that can be transferred. In addition, as another method, it may be used, including the ⁇ dress of the information storage device 5 f to members some truth be sampled.
  • the recipient may need to verify that all the original information is complete.
  • the original plaintext parts, all ciphertext parts, or a set of message digests of each plaintext part, or the message digest of each ciphertext part By attaching a message digest created by using a hash function to one or a set of combined information using a hash function, or by attaching a digital signature to this message digest, Even if the information is transferred to a completely different device, the integrity of the entire broadcast message can be verified.
  • the same information encryption process and the same member list are used for communication over a plurality of protocols for each part, and the members set by the team master are surely used.
  • Broadcasting can be performed between each part
  • the level of security and certainty of 131 broadcasts can be equalized.
  • the present embodiment is effective in a case where messages of different formats are simultaneously broadcast in a broadcast communication system.
  • a voice chat broadcast system members across multiple companies may have business negotiations and simultaneously transfer contract files, or use a mailing list broadcast system.
  • a mail message is sent to members, and a large file (for example, a 5 Mbyte image file) that exceeds the capacity of the mail system is transferred.
  • a large file for example, a 5 Mbyte image file
  • voice chat when the contract file is transferred, if the voice chat is interrupted and the broadcast is interrupted, important confidential information is handled. There is a risk that oversight may occur.
  • the allowable amount depends on the setting of each receiving mail system (for example, 3 Mbytes in the system of member A, 1 Mbyte in the mail system of one member).
  • the receiving capacity differs depending on the amount of free space in the mail receiving buffer reserved for a specific member, and it is difficult for the sender to assume that the message can be sent reliably.
  • the present embodiment functions effectively in these environments.
  • the security of the public key included in the member list used at the time of encryption is improved by verifying its validity before being used for encryption. For example, when the team master creates a member list, even if all public keys are valid, even if they try to use the same key after a certain period of time, they will not use it.
  • Each embodiment of the signal information creation device 2f has a key validity verification function similar to the function of verifying the validity of the public key and the private key used for the digital signature of the member list management device 1f. This further improves safety.
  • FIG. 60 embraces and illustrates the fifth to fifth to fifth to fifth embodiments of the encrypted information decrypting apparatus of the present invention.
  • the decryption unit 3 b £ first refers to the key selection information included in the encryption information and selects the encryption key to be used for decryption from among a plurality of encryption keys corresponding to one member as shown in Fig. 58. Select Then, the encryption key is decrypted by using the recipient's private key by using the public key cryptosystem to obtain a common key. Then, using the common key cryptography, the cipher text included in the cipher information is decrypted using the common key to obtain a plain text broadcast message.
  • a message digest MD f obtained by decrypting the digital signature with the sender's public key and a message digest MD ' ⁇ ⁇ obtained by compressing a broadcast message (plain text) obtained by decrypting the cipher text using a hash function are obtained. Compare / verify and check for falsification and sender.
  • FIG. 133 As an embodiment of the fifth-second c of the encryption information decryption device 3f , FIG. 133
  • a reception notification transmitting unit 3 for transmitting a reception notification to the information relay device for further confirming that the recipient himself / herself has received the encrypted information decryption device of the 5-1c embodiment of the present invention 3 Take a configuration with cf.
  • the reception notification transmitting unit 3c £ transmits, for example, a reception notification in which a digital signature is attached to a message digest of the received communication content, a time stamp of the reception time, a recipient ID, and the like.
  • the encrypted information decryption device 3t of the present embodiment is provided with the above-mentioned reception notification transmission unit 3c ⁇ .
  • the recipient himself / herself can send a reception notification with a digital signature attached to the information relay device. It is possible to confirm that the distribution was successfully made to one of the members registered in one list.
  • the multi-part receiving unit 3 d ⁇ determines whether a part of the part has been transferred to the information storage device 5 £ based on the content of the broadcast message as shown in FIG. 59, and if the packet has been transferred, If it is, contact the information storage device 5f and 134 Acquire parts using the most suitable protocol for transmission (for example, HTTP protocol ⁇ FTP protocol). Further, when the encryption information is composed of a plurality of parts, the decryption unit 3b ⁇ of the present embodiment operates so as to perform the decryption processing for each part.
  • the broadcast message is composed of a plurality of parts, and the information storage device 4 ⁇ ⁇ ⁇ in which some of the parts can be referred to from the information relay device 4 ⁇ by the above-described signal information creating device 2 ⁇ . This corresponds to the case of being transmitted to
  • the fifth to fourth c-th embodiment of the encryption information decrypting apparatus of the present invention is the encryption information decrypting apparatus according to any of the fifth to fifth-third embodiments. It is configured to further include a broadcast security verification unit 3 e in the decryption device 3 ⁇ .
  • the broadcast security verifier 3 e ⁇ operates as one of its functions to verify whether the sender is a member registered in the member list. At the time of verification, to confirm the sender to get the member list from the list acquisition storage unit 3 f f described below. In addition, by accessing a resource database that registers information about the member list placed on the network (for example, using a protocol such as LDAP), it is possible to check whether the sender is included in the member list. , You may ask. Further, a function similar to that of the broadcast security verifying unit provided in the information relay device described later may be further provided.
  • a fifth to fifth c-th embodiment of the cryptographic information decryption apparatus of the present invention is a cryptographic information decrypting apparatus according to any one of the fifth-to-first to fifth-fourth c-embodiments. 135
  • the configuration is such that the decryption unit 3 f is further equipped with a list acquisition and storage unit 3 ft.
  • the list acquisition and storage unit 3ff stores the member list stored in the resource database located on the network in the same or different protocol (for example, When using SMTP for broadcast communication, use HTTP, etc.).
  • the transferred member list is stored in a storage device (not shown), and obtained by reading the member list from the storage destination when necessary.
  • the list acquisition storage section 3 f f, member list is operable to check whether the latest version.
  • a database located on the network that stores information on the latest version of a member list may have the same or a different protocol than broadcast (for example, using SMTP for broadcast). In this case, use LDAP, OCSP, etc.) to check the latest member list version.
  • the list acquisition and storage unit 3f £ has a function of verifying the validity of the member list described in the embodiment of the member list management device 1E described above. Verify the validity of the list.
  • the function for verifying the validity of the public key and the secret key used for the digital signature described in the above-described embodiment of the cryptographic information creation device is provided by the decryption unit 3 b E and the list acquisition and storage unit 3 f. It is good also as a form used in preparation for ⁇ . Providing these functions further enhances safety.
  • FIG. 61 shows the implementation of the 5th to 6th d of the information relay device of the present invention. Includes and represents 136 forms.
  • the distribution destination list management unit 4a ⁇ that stores and manages the distribution destination list managed by the team master and the transferred cryptographic information are stored in the distribution destination list included in the distribution destination list. It consists of an information duplicating unit 4 b f that is duplicated for transfer to the member, and a transmitting unit 4 c £ that transmits the duplicated cryptographic information to each of the distributed members.
  • the distribution list management unit 4 a ⁇ has a function of storing and managing a distribution list, a function of acquiring and storing a member list, and an embodiment of a member list management device when acquiring a member list.
  • the distribution list management unit 4a a sets the distribution list with reference to the member list
  • the distribution list management unit 4a further has a function of checking whether the member list is the latest version.
  • a database located on the network that stores information about the latest version of a member list may have the same or a different protocol as broadcast (for example, when using SMT II for broadcast). LDAP, OCSP, etc.) may be used to query the latest member list version.
  • Embodiment of the 5-2 d of information relay apparatus of the present invention the first 5-1 d embodiment of the information relay apparatus 4 f, the configuration further comprising a list validity confirmation portion 4 d f Take. 137 list validity confirmation portion 4 d f, when acquiring the main Nba one list verifies the main emission Barisu preparative validity.
  • the function of verifying the validity of the member list is as described in the embodiment of the member list management device 1 described above.
  • the information relay device 4 ⁇ according to the fifth to first or fifth to second embodiments further includes an additional information attachment part 4cs. Take the configuration.
  • the additional information attachment 4c £ attaches various information (service information, management information, etc.) by the team master 1 or the administrator of the information relay device 4E to the encryption information. With the function of attaching the additional information, a wide range of services can be provided to the members to be distributed.
  • the fifth to fourth d embodiments of the information relay device of the present invention are provided in the information relay device 4 ⁇ according to any one of the 5-1 d to fifth to third d embodiments, for verifying the broadcast security.
  • the configuration further includes a part 4 ff.
  • the broadcast security verification unit 4 f ⁇ has a function to verify the identity of the member list as the first function. For example, if the terminal on the sending side is broken or the communication line is disconnected, the latest member list may not be available to the sender.
  • the broadcast security verification unit 4 f ⁇ includes a list of members used to encrypt the transmitted encrypted information and a list of destinations used by the server during transmission to further enhance the security of the broadcast. Verify the identity with the member list used to create the list. 138
  • the member list was used. Can be verified to be the same.
  • identity verification can be performed by verifying whether the digital signers attached to the member list are the same.
  • identity verification can be performed by comparing the message digest with the member list using a hash function.
  • the broadcast security verification unit 4ff has a second function of verifying the broadcast sender. In the conventional broadcast communication, since the administrator of the information relay device 4f was able to see the contents of the information, it was possible to inspect the contents, for example, whether or not slander or slander information was flowing.
  • the broadcast communication security verification unit 4ff sends the information terminal that refuses to receive the information (for example, it can be identified by an IP address) or the user's identification information (for example, in the case of a mail system, It obtains the rejection information including the e-mail address and the certificate issued by a trusted certificate authority), and sends the information or the sending terminal of the information transferred to the information relay device 4 £. Has a function to verify whether or not it is included in the reception refusal information.
  • the rejection information includes, for example, the e-mail address of an individual who has sent spam in the past, or the IP address / net address of a terminal whose security level is low and personal identification may not be performed in a legitimate manner. Contains a list of network addresses. 139
  • the broadcast security verification unit 4 f ⁇ has a third function of verifying the contents of the broadcast. This verifies the sender and communication contents in order to increase the security of the broadcast. It verifies that the sender of the cryptographic information is included in the member list, and verifies that the transmitted information contains a malicious program or data string.
  • the broadcast security verifying unit 4f £ makes sure that, of the cryptographic information composed of a plurality of parts, the parts stored in the information storage device and referred to by the cryptographic information decryption device are surely stored. It has a function to verify that it has been transferred to the device. Refers to the transmitted cryptographic information, determines whether some of the cryptographic information composed of multiple packets has been transferred to another information storage device, and transfers some to another information storage device. If so, verify that the transfer was successful.
  • the function of verifying the validity of the public key and the private key used for digital signature described in the above-described embodiment of the cryptographic information generation device is provided in the broadcast security verification unit 4 f ⁇ and used. There is also a form to be performed.
  • the fifth through fifth embodiments of the information relay apparatus according to the present invention are the same as those of the fifth through fifth embodiments, except that the broadcast relay contents storage unit
  • the configuration is further provided with 4 gf.
  • Broadcast content storage unit 4 g f the information has been transferred or a part of the information, or, to save and attach attachments on the information. For example, if the mail server in the mail system fails or if the recipient's terminal is out of order, the information sent will not be correctly received. 140 possible. In some cases, the audio is interrupted due to the communication line in the audio chat. Even if the data sent by the sender and the data received by the receiver do not match in this way, the data can be safely stored by the storage function using the broadcast content storage unit 4 g £, You can check it again and get it again when it becomes unavailable.
  • the fifth to sixth d embodiments of the information relay device of the present invention are the same as those of the 5-1d or the fifth to fifth d embodiments. 4 h ⁇ ⁇ ⁇ is further provided.
  • the broadcast automatic opening section 4h ⁇ automatically starts the broadcast without obtaining the manual permission of the server administrator.
  • the administrator of the information relay device it was necessary for the administrator of the information relay device to perform the work associated with the establishment in advance. For example, it was necessary to set distribution lists, distribute IC cards, and register public keys in information relay devices.
  • cryptographic broadcast is not an endless communication, but is a communication that uses a minimum amount of time when necessary, such as one hour of voice chat and three contract file transfers. It is thought that there are many cases. In that case, the work burden on the start or delete the broadcast of information relay apparatus 4 f becomes very large. In addition, there is a danger of mistakes and the presence of a malicious administrator. Therefore, a system that requires as little manual setting as possible by humans is desirable for safety. Therefore, the information relay apparatus 4 f of the present embodiment, without the need for manual configuration of the server administrator, satisfies certain conditions of use (e.g., charges proportional to the usage time of payment, etc.), Provides a function to start broadcasting automatically.
  • certain conditions of use e.g., charges proportional to the usage time of payment, etc.
  • the broadcast automatic opening unit 4 h f is, opening the requester is opened accepted the request, which has been transferred, may be e Bei the establishment request confirmation function to verify whether or not an accurate request. For example, if a credit card is described in the billing item, verify that the credit card number is properly registered and billable. During this verification, the information relay apparatus 4 f data used for verification when had no queries the data base Ichisu or server or the like having a predetermined data is arranged on the network.
  • the information relay apparatus 4 f may be provided with a withdrawal request receiving unit that receives a request for withdrawal members one broadcast (not shown).
  • the withdrawal request receiving unit when the withdrawal request receiving unit receives a withdrawal request that the member of the broadcast withdraws from the broadcast to the information relay device, the withdrawal request is transferred to the member.
  • a withdrawal request reception unit is provided to cancel the request and notify the team master of the reason. You can also use identity verification techniques such as digital signatures and shake hands to determine if the withdrawal request is definitely a withdrawal request member—the transfer cancellation request you created.
  • Embodiment 5-1 of the broadcast communication system of the present invention an example in which a securities company distributes securities news to members using an information relay device operated by a third party will be described.
  • the function of the information relay device of the present invention is realized using a mailing list server and a WWW server in order to realize secure broadcast communication of the mail system.
  • This mailing list server is operated by a third party.
  • the WWW server has items set by the mailing list server administrator to establish a broadcast and must be met by the requester. Is stored.
  • the securities company downloads this website using SSL (Secure Socket Layer) communication and fills out the form corresponding to the item displayed on the browser. input.
  • SSL Secure Socket Layer
  • the broadcast permission automatic opening unit 4h ⁇ implemented as a program running on the server (for example, CGI) has a function to determine the permission to open the 4h ⁇ .
  • ⁇ ⁇ “Using the four data of 1000 j, it is decided whether or not to allow the establishment.
  • the credit card No is used as a credit card service company. And verify that the cardholder and the certificate holder match, and if so, forward the page to the subscriber requesting permission to open. If not, The page notifying that the establishment has been rejected is transferred to the subscription requester again.
  • SSL Secure Socket Layer
  • the requester is managed as the team master by the broadcast opening setting function of the broadcast automatic opening unit 4h ⁇ implemented as a program running on the mailing list server.
  • a distribution list (initially an empty list) for distributing the information sent to this mailing list address is set.
  • the mailing list server forwards a message to the team master indicating that the opening settings have been successfully completed.
  • the member list management device 1 £ in Example 5-1 is implemented, for example, as a JAVA applet, incorporated in a homepage, and stored in a WWW server.
  • the team master manages the member list to be set using the applets downloaded using SSL communication.
  • the member list in the embodiment 5-1 is composed of three lists: a team master list, a reporter list, and a recipient list.
  • a team master list set a submaster who can manage the team in addition to the team master, register reporters who write security news in the reporter list, and digitally sign the team master Then, transfer the information to the information relay device 4 ⁇ again.
  • the information relay device 4f sets the distribution list after verifying the digital signature to make sure that the member list is definitely created by the team master.
  • the delivery rule in the embodiment 5-1 is that the broadcast information transferred from the members of the reporter list is copied and registered in the receiver list (included in the member list).
  • the subscription request receiving unit 1 of the member list management unit 1 is installed so that the receiver can be automatically subscribed to any user who can perform monthly billing. Use d ⁇ .
  • a plurality of submasters are set in the team master list included in the member list set by the team master.
  • the submaster is also an employee of a securities firm, who is responsible for managing the recipient list.
  • the submaster downloads the subscription request item setting function of the subscription request receiving unit 1 df implemented as a WWW page using SSL communication.
  • the WWW server sees the certificate of the submaster that can be obtained by SSL communication, and performs identification and authentication of the submaster. By setting up each item of the form on the WWW page, you can set the required items for subscription.
  • a service contract agreement, a billing item, an e-mail address and a certificate including an e-mail address are to be presented, and further, the enrollment request of the enrollee is encrypted.
  • Requesters to subscribe to the securities news distribution service use the subscription request item presenting function of the subscription request reception unit 1 ef implemented as a JAVA applet embedded in the WWW page, and first enter the contract agreement.
  • Use your private key to digitally sign, and enter your billing items and email address.
  • the confidential information especially billing information: credit card No and bank account number, etc.
  • Subscription requests from a large number of subscription requesters are stored as encoded subscription request information on a WWW server.
  • a program that implements the subscription permission determination function of the subscription request receiving unit le E accesses the WWW server, acquires encrypted subscription request information, and allows each item to permit service subscription. To determine if it has been met. For example, use the key validity verification function to verify that the public key and private key are still valid. As a result of the judgment, a notification e-mail indicating that the subscription was permitted or rejected is forwarded to the subscriber.
  • This program can further automatically operate the member list management device.
  • the member list stored in the WWW server is used by the member list management device 1f, and the member list acquisition and storage unit 1c ⁇
  • the subscriber is registered in the recipient list of the member list.
  • a digital signature is attached to this list of recipients using the secret key of the submaster registered as the submaster and a new member list is transferred to the WWW server again.
  • the WWW server verifies the validity of the member list by using the function for verifying the validity of the member list described above, and verifies the validity of the public key and the private key used for digital signature. Verify whether all public keys included in the member list are valid using the function.
  • the distribution list is updated using the distribution list management unit 4a a. Also, for members included in the reporter list, the latest member list is sent to the list transmission unit 1 d £ (in the embodiment, this is implemented using the SMTP protocol. ) And send it.
  • the terminal on which reporters create securities news is a general-purpose computer.
  • an e-mail software is installed in a notebook computer, etc.). Attempts to transfer articles created using this email software by specifying the address of the mailing list.
  • the cryptographic information creation device 2 ⁇ ⁇ implemented as plug-in software linked with the e-mail software uses the destination inspection unit 2 c ⁇ to determine whether the mailing list address is a member list.
  • the plug-in software first uses the list acquisition and storage unit 2a to verify whether the version of the member list existing on the terminal personal computer is the latest version. It queries the latest version of a resource database built on the network based on the X.500 standard using LDAP. If it is not the latest version, the latest member list is obtained from the location of the latest version registered in the resource database (in this embodiment, it is obtained from the WWW server using SSL communication).
  • the cryptographic information creating apparatus 2 f after confirming the validity of the members one list by using the function to verify the validity of the members one squirrel Bok, the public key of the members of the recipient list that is included in the members one list The encryption is performed by the encryption unit using.
  • the digital signature addition function acquires the reporter's private key from the IC card that records the private key held by the reporter, and attaches a digital signature to the created article.
  • This digital signature allows the recipient to verify which reporter wrote the article and to verify the authenticity of the article. Also, reporters who have delivered articles cannot deny that they created the article.
  • the mailing list sent to the address of the mailing list is the digital signature attachment of the information sent by using the broadcast security verification unit 4fE (in this example 5-1, , Reporter) Power ;, make sure that it is definitely included in the reporter list of the member list.
  • the function to verify the identity of the member list is used to verify whether the versions of the member list are different.
  • the cryptographic information is duplicated using the information duplication unit 4b ⁇ , and the members included in the list of recipients in the member list are implemented using the SMT protocol.
  • the encryption information decryption device of the present invention implemented as plug-in software embedded in the recipient's e-mail software uses the function of verifying the digital signature of the decryption unit 3 b ⁇ to perform tampering. Check the existence and creator of the information, and confirm that the sender is a reporter of a securities company. After confirmation, the article can be decrypted and read.
  • a reception notification is sent to the information relay device 4 £ using the reception notification transmission unit 3 c £.
  • the Java applet in the present embodiment is really malicious, it can be verified by checking the digital signature attached to the JAVA applet.
  • Embodiment 5-2 of the broadcast communication system of the present invention An example will be described in which 148 members are used to broadcast confidential information such as estimates and negotiations between members (this set is referred to as team 011 £ ).
  • a mailing list server is used as an information relay device.
  • the team master of team 0 1 f uses a member list management device 1 ⁇ implemented as an executable file on the OS of a general-purpose desktop computer, and the member list that broadcasts confidential information. Performs management. To get the members list using a list acquisition storage unit 1 c f, open the list creation and change GUI screen.
  • a list of members of Team 0 1 1 £, a public key database on the terminal is accessed using the public key management unit 1 b £, and a list of stored public keys is displayed. It's shown.
  • the team master of team 001 f selects the public key of the member who joins the team from the public key list, and adds it to the list of members of team 001 e.
  • the user can access the directory service provided by the certificate authority on the network and use the public key that did not exist in the terminal. Obtain the public key of the member you want to add to Team 0 0 1 ⁇ and add this public key to the list of members.
  • the ⁇ ⁇ button is displayed on the GUI screen.
  • the function to verify the validity of the public key and the private key used for the digital signature is performed by the directory of the certificate authority that issued the certificate containing each public key included in the member list. Access the service using the LDAP protocol and verify that this public key is valid. Validation reveals invalid public key If so, a dialog is displayed to inform the team master. If everything is valid, create a member list consisting of a timestamp, the address of the mailing list, the team ID, and the distinguished name of the team master, and then use the hash function to compile the entire data of this member list. Compress using MD5 to generate compressed data.
  • the secret key of the team master is accessed, and the password is decrypted using the password input by the team master from the dialog box (in this embodiment, the password decryption implemented using the common key cryptosystem RC2). Use of conversion).
  • the digital signature is created by encrypting the compressed data with the public key encryption method RSA using the secret key of the team master obtained as a result.
  • This member list and digital signature are transferred to the information relay device 4f as mail using the SMTP protocol.
  • the information relay device 4 ⁇ uses the member list acquisition function of the distribution destination list management unit 4af to transmit the SMTP mail composed of the received multi-part (MIME (Multipurpose Internet Mail Extensions)) format.
  • MIME Multipurpose Internet Mail Extensions
  • the contents are analyzed, and the member list part determined from the Content-Type is extracted and input to the list validity confirmation unit 4 d ⁇ .
  • the list validity confirmation unit 4 d ⁇ verifies that the digital signature of the team master of team 01 f is definitely attached as the digital signer of the member list, and the distribution list management unit 4 Use a to change the recipients of the distribution list. Then, for the recipients of the distribution list that has just been changed, the member list and the digital signature are copied for each MIME format and transmitted to each recipient of the distribution list. 150
  • the cryptographic information creation device 2 ⁇ that operates as a mailer installed on a general-purpose desktop computer 2 ⁇ receives the mail including the member list, it — From Type, this mail is identified as a member list in the broadcast.
  • the mailer extracts the member list and the digital signature, uses the function to verify the validity of the list, verifies the validity of the member list, and then obtains the list. Save using the storage unit 2 a ⁇ .
  • Members included in Team 01 use the broadcast information creation function of the encryption information creation device 2f implemented as a general execution program that runs on a general-purpose desktop computer.
  • the destination inspection unit 2c £ checks the destination address, and multiple members whose destination addresses are stored on the terminal Members of the list that are private to the destination address — check for a list. If there is a member list, the attached file and mail are encrypted using the member list's public key.
  • the encryption unit 2b ⁇ separately encrypts each attached file and the mail text, and individually attaches a digital signature.
  • the attached file is transferred to the information storage device (information storage server) 5 ⁇ without attaching it as it is.
  • the multi-part transmission unit 2 d ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ queries the database on the network for the information storage device 5 ⁇ corresponding to the mailing list address, and Identify the address of the information storage device 4 ⁇ ⁇ ⁇ to be sent and the transmission method (eg, protocol). 151 If the information storage device 5 £ is found to be a mechanism that permits file transfer using the HTTP protocol, it transmits using the HTTP protocol.
  • the information storage device 5 £ can use SSL communication to authenticate the user, the information storage device 5 £ can be used for the member list using the broadcast service provided by the mailing list server. You can check if it is included. In the body of the mail, the address of the information storage server is attached and the address is transferred separately from the transmission of the two attachments. First, the mailing list sent to the address of the mailing list contains the digital signature of the information sent using the broadcast security verification unit 4ff. Check that it is included in the reporter list. In addition, the function to verify the identity of the member list is used to verify whether the versions of the member list are different. If the version of the member list is different as a result of the verification, information indicating that fact and the broadcast information are returned to the reporter.
  • the communication content include any malicious programs or viruses that use equipment / software bugs? Verify Furthermore, using the information storage device reference function of the broadcast security verification unit 4 f £, it is verified whether the two attached files that were definitely encrypted were transferred to the information storage device 4E and stored. I do. As a result of the above verification, if everything is normal, the contents of the broadcast are stored in the database connected to the mailing list server using the broadcast contents storage unit 4 g £. At that time, a digital signature using the time stamp and the private key of the mailing list server is attached and saved. In addition, it was confirmed that the attached file was stored in the information storage device 4 ⁇ ⁇ for the encrypted information.
  • the falsification / information creator is confirmed by using the function of verifying the digital signature of the decryption unit 3b ⁇ , and further, the broadcast security verification unit 3eE Use the sender's reliability check function to confirm that the member is a business partner included in the list.
  • the decryption unit 3b ⁇ is used to decrypt the information and look at the encrypted information, it is clear that the attached file has been sent to the information storage device 5 ⁇ .
  • Multipart receiving unit 3 d f downloads this attachment by using the HTTP protocol, it again decrypt it files, it is possible to obtain the original information.
  • each device in the embodiment 5-2 has been described above.
  • the present invention may use a network such as a LAN or a dial-up, in addition to the Internet.
  • a program for realizing the member list management device of the present invention is recorded on a computer-readable recording medium, and is recorded on this recording medium.
  • a program may be loaded into a computer system and executed to perform member list management.
  • the member list management program combines a function of creating a member list including one or more public keys of one or more members performing broadcast communication, and a function of acquiring and storing the public key. Realize it in one step.
  • a program for realizing the encryption information creation device of the present invention is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into a computer system and executed. ⁇ information may be created.
  • the encryption information creation program has a function of acquiring and saving a member list via a network, acquires a broadcast message, and includes the broadcast message in the member list.
  • a computer is made to realize the function of encrypting information using a public key to generate encrypted information.
  • a program for realizing the encrypted information decrypting device of the present invention is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into a computer system and executed.
  • Information decryption may be performed. That is, the encryption information decryption program causes a computer to realize a function of acquiring the encryption information transferred from the information relay device and a function of decrypting the encryption information included in the encryption information.
  • a program for realizing the information relay device of the present invention is recorded on a computer-readable recording medium, and the program recorded on this recording medium is read by a computer system and executed to execute information relay. Processing may be performed. That is, the information relay processing program has a function of managing the distribution destination list, a function of copying the transferred encrypted information, and 154 A combination of a function that distributes the produced encrypted information to each distribution destination: one. Also, in order to realize broadcast in a mobile network environment, a terminal that does not have a member list management device, an encryption information creation device, and an encryption information decryption device of the present invention required for broadcast must be used.
  • the software that realizes the functions of each device is downloaded from the software storage device that is located on the network on this terminal and stores the software that realizes the functions of each device, and Broadcasting may be performed by reading and executing the computer system built in the PC.
  • the 5th-la to 5-4a, the 5th to lb to 5b, the 5th to lc to 5c, the 5th to 1c! According to the invention of the embodiments from 5 to 6 d, the following effects can be obtained.
  • the information that is encrypted in the information relay device is not decrypted, it is possible to prevent the information relay device administrator from improperly leaking or falsifying the communication content of the broadcast communication, and Broadcast content can be shared only with members who need to share the information.
  • a subscription request receiving unit is provided in the member list management unit, and a broadcast automatic opening unit is provided in the information relay device, so that a receiver performing broadcast communication withdraws, It can respond quickly to subscriptions and can prevent information from being erroneously transferred to members who should not broadcast, even if the broadcast members change dynamically.
  • the administrator of the information relay device since the management is performed by the member list, the administrator of the information relay device does not manage the member to be distributed in the broadcast, but manages the member. 155 It is possible to manage the members to be delivered among members who perform broadcast communication, and it is possible to reduce the management burden concentrated on the member managers.
  • the information relay device is provided with a broadcast security verification unit and a broadcast content storage unit
  • the encrypted information decryption device is provided with a reception notification transmission unit and a broadcast security verification unit.
  • the invention of the sixth embodiment is for sharing various kinds of information and various functions provided to users between team members (users or members) corresponding to organizational units such as company departments and sections. It is related to a team data list processing system that creates, manages, and stores a team data list, and thereby safely shares this information and functions among users for each team. More specifically, a team data list storage device that performs processing related to the storage of team data lists, and a team data list that performs various management on the team data list obtained from the team data list storage device This is related to a system equipped with a network management device. With respect to the invention of the sixth embodiment, the following technology has been known.
  • ACL access control list
  • FIG. 76 shows an overview of a conventional system that uses ACLs to share information among multiple users.
  • intranet 1 and internet 2 are connected to server 5 through firewalls 3 and 4, respectively.
  • sharing members 6 outside the intranet are sharing information with each other via the internet 2.
  • intranet 1 is a closed network, such as a network established within a company
  • internet 2 is a public network that spans the globe.
  • the firewalls 3 and 4 are computers that prevent malicious intruders and others from illegally accessing the intranet 1.
  • the server 5 ⁇ is a terminal (computer) storing various resources, a database 7 ⁇ ⁇ storing shared information, a group that can access specific information or functions, and a member list of members belonging thereto.
  • the server 5 has a data storage function for managing shared information stored in the database 7 and a user authentication function for verifying whether or not a communication partner corresponding to a client is an authorized person in advance. Function, access control function that verifies whether access to shared information is possible based on ACL 8 ⁇ , and group management that enables only members belonging to a specific group to access specific shared information based on ACL 8 ⁇ . Has functions. 157 ⁇ In the system shown in Figure 76, when a user inside the shared member 6 intranet 1 receives an access request to the database 7, the server 5 refers to the ACL 8 and authenticates the user each time.
  • FIG. 77 shows an example of a conventional implementation in which only members belonging to a specific group share information.
  • Server SV # in the figure corresponds to server 5 # in FIG.
  • the client is a terminal operated by a person inside the shared member 6 intranet 1 in Fig. 76.
  • a member list 9 ⁇ ⁇ is provided on the server SV ⁇ .
  • Each group—List 9 is a group ID that is an identifier assigned to the group, a public key of each member in the group, and a public identifier that is assigned to these public keys. It consists of a key number (public key No in the figure), and has a digital signature of the team master of the group.
  • the server SV ⁇ performs a predetermined authority check, and then performs a corresponding operation to the specified group ID.
  • the member list 9 is transferred to the client CL as a public key ID list. After confirming that the digital signature of the team master included in the list is valid, the client CL II groups the sent member list into a group.
  • a member list 9a a is created by adding or deleting the member's public key and public key ID in response to the member's joining or leaving the group.
  • the client CL # digitally signs the member list 9a #, sends a request for updating the member list to the server SV #, and returns the member list 9a #.
  • the server SV # receives the member list 9b # from the client CL and updates the group on the server SV #.
  • the administrator of the server 5 ⁇ and the server SV ⁇ is given the authority to set and manage the ACL 8 ⁇ ⁇ ⁇ . I have. Therefore, these server administrators can make unauthorized access to ACL 8 ACL, and there is a drawback that it is not possible to prevent the contents of ACL 8 ⁇ from being tampered with intentionally.
  • ACL8 may be tampered with by anyone other than the server administrator who invades the server SV II (so-called cracker).
  • the invention of the sixth embodiment has been made in view of the above points, and its purpose is to prevent a server administrator storing a team data list from managing the team data list.
  • the team data list in the present invention is a general term for a list that defines information about a team, and refers to a “set of members” applied to applications requiring highly confidential management such as the ACL described above. It is for definition.
  • terminal administrators, network administrators, and server administrators who are not members of the team can change information about the team.
  • the team data list of the present invention the information on the team is divided into a plurality of lists (one or more members and a team master list as described later) and managed, whereby the team master itself is managed.
  • FIG. 67 roughly illustrates the configuration of a system premised on the present invention, and is a system configured by connecting a client and a server SV # via a network NW #.
  • the member list describes members who can access resources such as various types of information and functions provided to users.
  • the server SV ⁇ ⁇ is connected to a database 10 ⁇ ⁇ constructed on a hard disk or the like.
  • This database 10 ⁇ has a group (group ⁇ ⁇ , ⁇ ⁇ in the figure) to which a plurality of members belong.
  • the corresponding member lists 11 1 and 11 1 are stored.
  • the server SV ⁇ ⁇ has only a member list storage function.
  • the client CL changes and returns the member list, and the member list on the database 10 1 11 ⁇ ⁇ and member list 1 1 Replace the contents of ⁇ ⁇ .
  • Client CL II has a member list management function.
  • One of the member list management functions is a function of changing the member list.
  • the client CL II modifies the member list obtained from the server SV ⁇ according to the addition or deletion of members and returns it to the server SV ⁇ . To do it.
  • the server administrator ⁇ cracker, etc. operates the server SV ⁇ , and the member list on the client CL side is obtained.
  • the member list on the server SV ⁇ ⁇ can be falsified without the intervention of the port management function. Moreover, if a server administrator or the like illegally falsifies a member with his / her digital signature, there is a problem that the client CL cannot distinguish it from a legitimate administrator. To avoid this kind of inconvenience, the system shown in Fig. 67 adds digital signatures 12 1 and 12 2 to the member lists 11 ⁇ and 11 1, respectively. To cope with this, the client CL II has a digital signature function as a part of the member list management function, and the private key is transmitted from an IC (integrated circuit) card or the like in which the private key file or private key is recorded.
  • IC integrated circuit
  • Fig. 68 outlines the procedure for changing the member list on the server SV # from the client CL # side.
  • the member list 20 stored on the server SV ⁇ includes the members that make up the information sharing group team ⁇ 1 ..
  • the team master ⁇ ⁇ ⁇ ⁇ on the client CL ⁇ side has a group ID (identifier) for identifying the group or team, and a user public key in the public key system (that is, a predetermined length). Bit 162), and sends the user public key number (user public key No in the figure) to the server S ⁇ ⁇ , and requests the server SV ⁇ ⁇ to send the member list (step S l). .
  • the “user public key number” is information for identifying and authenticating the user such as the team master TM ⁇ , and is a serial number assigned in advance to each user public key. is there. More specifically, the user public key number is information corresponding to each user public key for uniquely identifying the user public key. For example, the user public key number is included in a certificate issued by a certificate authority. This is the serial number of the certificate. Also, as information for identifying and authenticating the user himself / herself, various information such as an ID and a name for actually identifying the key creator himself / herself can be used in addition to the user public key number just described. .
  • the server SV # confirms the authority of the team master ⁇ @ ⁇ , as described in detail below, based on the group ID and the user public key number sent from the client CL (step S2).
  • the server sv identifies and authenticates the team master ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ .
  • this process will be described in accordance with the procedure shown in FIG. First, as described in step S2 ⁇ in FIG.
  • the client CL ⁇ accesses the server SV ⁇
  • the user name and user public key (actually, the user public key number described above) are collected.
  • the server SV ⁇ ⁇ generates a random number and stores it internally, and encrypts the random number with the user public key (corresponding to the user public key number) (step S 102 ⁇ ) and encrypts the random number.
  • Send data to client CL CL as “challenge data” (Step S103).
  • the client CL ⁇ decrypts the challenge data sent from the server SV ⁇ with a secret key corresponding to the user public key (step S104), and uses the obtained decrypted data as a “challenge response” in the server.
  • Step S105 The server SV confirms the communication partner by comparing the challenge response sent from the client CLC with the random number generated in step S102 ⁇ . That is, if they match, it is possible to confirm that the person who knows the secret key corresponding to the user public key sent in step S101 is the communication partner (successful authentication). On the other hand, if the two do not match, it can be understood that the communication partner may not be a person with valid authority (authentication failure) (step S106 6). Thereafter, the server SV # notifies the client CL # of the confirmation result (authentication success or authentication failure) obtained in step S106 # (step S107 #).
  • the server checks whether the user public key number sent from the client CL # is included in the member list 20 # and checks the user (in this case, Check if the team master)) has the authority to change the member list 20 ⁇ .
  • the user public key number sent from the client CL # is described in the member list 20 # corresponding to the team ⁇ 1 ⁇ specified by the group ID.
  • server SV # notifies client CL # of authentication failure.
  • the server SV acknowledges the request for rewriting the member list by the team master ⁇ ⁇ ⁇ ⁇ because the digital signature in the member list 20 is that of the team master ⁇ ⁇ .
  • Step 164 transfers C to the client CL side (Step 164 pp ⁇ 3 ⁇ ).
  • the client CL checks the digital signature in the member list 20 ⁇ , and since the digital signature is the one assigned by the team master ⁇ ⁇ ⁇ , the member CL 20 ⁇ is tampered with on the server SV ⁇ side. Confirm that it has not been performed and is valid (step S4).
  • the client performs a member change process of replacing the member MB No. in the member list 20 No. with the member MC No. to create the member list 21 No. (Step S5 No.).
  • the digital signature is deleted when the member is changed, so the client CL ⁇ adds the digital signature of the team master ⁇ ⁇ ⁇ to the member list 21 ⁇ . 22.
  • the management of the member list itself is performed by the administrator selected from the members in each team on the client CL CL side, and the server SV ⁇ side described above.
  • the system is designed to prevent unauthorized persons such as server administrators and crackers from tampering with the member list.
  • the present embodiment which will be described in detail below, is a further development based on the base technology described above, and achieves the above-described object of the present invention by incorporating the functions described below. I have. First, in order to reduce the burden on a single administrator when managing a member list of a department that has many people, a mechanism to manage the member list with multiple administrators is implemented.
  • FIG. 66 is a block diagram showing the configuration of the entire system of this embodiment including the team data list management device and the team data list storage device.
  • a team data list management device 30 3 and a team data list storage device 31 1 have a team data list management function and a team data list storage function, respectively, which will be described in detail below. Data is exchanged using the communication function.
  • Each of the team data list management device 30 ⁇ and the team data list storage device 31 1 can be realized by a general computer such as a workstation.
  • Stores programs for implementing the team data list management function and the team data list storage function (team data list management program, team data list storage program). These programs are stored in portable storage media such as floppy disks, IC (integrated circuit) cards, magneto-optical disks, CD-ROMs (compact disks—read only memory), and hard disks built into computers.
  • the program may be for realizing a part of the functions described in detail below, and further, these functions may be realized in combination with a program already recorded in the computer.
  • a team master can change a submaster or a member, or even his own team master.
  • general members other than the submaster and the team master are those who share information and functions, and have no authority to make changes to the contents of the team data list.
  • a storage device 32 # that can construct a database such as a hard disk is connected to the team data list storage device 31 # shown in FIG.
  • the storage device 32 @ 2 stores a set of a team data list including a member list 33 @ 3 and a team master list 34 @ 4 for each team composed of a plurality of members. Although only one set of the member list 33 3 and the team master list 34 4 is shown in the figure for the sake of explanation, there are actually as many as these teams.
  • Member list 33C provided to user It consists of a list of members that share information and functions that share information, such as member identification information, the public key given to the member, and the ID of the holder of the private key corresponding to this public key (hereinafter referred to as the “public key”). ID), a team ID that identifies the team, a digital signature of the list creator (ie, the team master or submaster), a timestamp indicating the time that the member list 33 was created, and a message within the team. It contains information on functions that can be used by members (for example, applications), and information on hierarchizing teams by comparing them to company organizations.
  • the member list 33 3 also includes information about each member, such as the e- mai 1 (e-mail) address and the member's own address.
  • the team master list 34 4 is composed of a list of team masters and sub-masters. Identification information of the team master or sub-master, public key, public key ID, team ID, digital signature of the team master, It includes a time stamp indicating the time when the master list 34 was created.
  • the team master list 34 4 contains information about the team, such as the number of team members, the time the team was created, and the various functions available to each member in the team. These can be used to manage information resources for each team at the same time.
  • the authority confirmation function 35 5 is requested or changed from the client CL ⁇ side to the member list 33 ⁇ ⁇ and the team master list 34 4.
  • the client CL authenticates the requester himself, and confirms whether this requester has the right to make changes or references.
  • member list 33 168 Starlist 3 4 Judge whether ⁇ ⁇ ⁇ should be transferred.
  • the list storage function 36 6 obtains these lists from the storage device 32 ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ when the authority confirmation function 35 ⁇ uses the member list 33 ⁇ and the team master list 34 ⁇ . Or the process of saving to the storage device 32 3. In the following description, it is assumed that when the authority confirmation function 35 ⁇ uses the member list 33 ⁇ or the team master list 34 ⁇ , the list storage function 36 ⁇ ⁇ always exists.
  • the list creator confirmation function 37 7 obtains the member list 33 3 or the team master list 34 4 from the team data list storage device 31 1. Verify that these lists have been created by an administrator with administrative authority (ie, team master or submaster). By this verification, it is possible to detect that an unauthorized person such as an administrator of the server SV ⁇ or a cracker who has illegally entered the server SV ⁇ has tampered with the member list 33 ⁇ ⁇ team master list 34 ⁇ . .
  • the list change function 38 is changed by adding, deleting, or replacing member managers to the member list 33 or team master list 34 obtained by the list creator confirmation function 37. Is added.
  • the digital signature function 39 9 changes the member list 33 3 and team master list 34 4 changed by the list change function 38 8 with a private key or digital signature key that only the changer can know. Digital signatures of those who modify these lists (that is, team masters or submasters) are added using the encryption and hash functions used together.
  • the public key management function 40 ⁇ accesses the public key database 41 1 connected to the team data list management device 30 ⁇ , and acquires the public key and the public key ID corresponding to the public key. .
  • the public Kagide - database 4 1 team data list managing unit 3 0 directly connected of the ⁇
  • the form that exists in a server (for example, a certificate authority) installed on a network such as the Internet can be naturally considered.
  • the public key management function 40 ⁇ accesses the public key database 41 ⁇ ⁇ ⁇ via, for example, a homepage registered on a certificate authority, and from there, stores the public key and public key ID described above in a file. It can also be obtained in the form.
  • the public key database 41 1 and the storage device 32 2 are configured separately from the team data list management device 30 ⁇ and the team data list storage device 31 1, respectively.
  • the public key database 41 1 may be included in the team data list management device 30 ⁇ , and the storage device 32 2 may be included in the team data list storage device 31 1. is there.
  • FIG. 70 shows a processing procedure for changing a member registered in the member list among operations performed when members are managed by a plurality of administrators.
  • the team data list storage device 3 1 ⁇ ⁇ ⁇
  • member MX ⁇ is registered as a team master
  • members MY ⁇ and ⁇ are registered as submasters.
  • those members for example, members , and members! ⁇ ⁇ shown in FIG. 70
  • those members are described as a team master MX ⁇ and a submaster MY ⁇ ⁇ ⁇ ⁇ , respectively.
  • the team data list management device 30 sends a change request for members to the team data list storage device 31 along with the group ID representing the team ⁇ 2 ⁇ and the user public key number of the submaster MY # (step 1).
  • Step S 1 1 ⁇ ) c In the team data list storage device 3 ⁇ , the authority confirmation function 35 ⁇ authenticates the submaster MY ⁇ ⁇ ⁇ ⁇ by the shake hand described above, and then the team specified by the group ID ⁇ 2 ⁇
  • the member list 46 ⁇ related to the user and confirming that the user public key number of the member MY ⁇ exists on the member list 46 ⁇ By referring to the team master list 45 ⁇ , the submaster MY ⁇ ⁇ Confirm that it is a submaster of team T 2 ⁇ ⁇ and has the authority to change members (step S 12 ⁇ ) 0
  • the authority confirmation function 35 ⁇ is designated
  • the team master list 45 and the membership list 46 related to the selected team ⁇ 2 ⁇ are transferred to the team data list management device 30 # (step S13).
  • the list creator confirmation function 37 7 is included in the team master list 45 5 and the member list 46 ⁇ transferred from the team data list storage device 31 1. Check the digital signatures to make sure that these lists are legitimate ones created by those registered in the Team Master List 45 ⁇ (in short, Team Masters ⁇ () S 1 4 ⁇ ) c 171
  • Team Masters ⁇ () S 1 4 ⁇ ) c 171 the details of the confirmation processing performed by the list creator confirmation function 37 ⁇ based on the tip of FIG. 71 will be described.
  • the list creator confirmation function 37 ⁇ obtains the team master list 45 ⁇ and the member list 46 ⁇ from the team data list storage device 31 ⁇ (step S 21 ⁇ ), and then, Check the digital signatures included in these two lists (Step S2 2 ⁇ ) 0 If the result of this check is that any one of the digital signatures has been tampered with, it is determined that an illegal act has occurred Cancel the current process of changing members, for example. On the other hand, if no tampering has been detected, the list creator confirmation function 37 ⁇ is assigned to the digital signature of the member list 46 ((that is, the member MX ⁇ ⁇ in FIG. 70) by the team master list 45 ⁇ .
  • Step S23 3 determines that there has been fraudulent activity and cancel the current processing in the same way as in step S22 ⁇ ( Step S23 3).
  • the list creator confirmation function 37 ⁇ subsequently checks whether the digital signer of the team master list 45 ⁇ (that is, the member ⁇ ⁇ ⁇ ⁇ in FIG. 70) is the team master (step S). 24 4)), and if it is not a team master, as in steps S2 2 ⁇ to 332.
  • the list creator confirmation function 37 3 sends the team master list 45 5 and the member list 46 6 to the list change function 38 8. 172
  • step S15 ⁇ in FIG. 70 the list change function 38 8 is described in the member list 46 6.
  • the member list 7 is created by replacing the member MB ⁇ ⁇ ⁇ with the member MC and sent to the digital signature function 9 ⁇ .
  • the digital signature function 39 ⁇ obtains the secret key of the submaster MY ⁇ from the above-mentioned secret key file and the like, and based on this obtains the member list 48 ⁇ ⁇ with the digital signature of the submaster MY ⁇ ⁇ attached to the member list 47 ⁇ .
  • the team master list 45 5 and the member list 48 8 are returned to the team data list storage device 31 1 (step S17 ⁇ ).
  • the authority confirmation function 35 5 verifies whether the transferred team master list 45 5 and member list 48 8 have been tampered with, and Verify the contents of these lists as follows.
  • the digital signer of the team master list 45 5 is the team master MX ⁇ , so its legitimacy can be understood.
  • the digital signer of the member list 48 ⁇ is the submaster MY ⁇ , and this submaster MY ⁇ ⁇ changes the member from the team master MX ⁇ by referring to the team master list 45 ⁇ that has been verified.
  • the authority confirmation function 35 ⁇ stops the processing without updating the team master list and the membership list (step S 1 8). As described above, the member change during the maintenance is performed. 173
  • step S31 In the team data list storage device 31 ⁇ , the authority confirmation function 35 ⁇ authenticates the team master MX ⁇ ⁇ ⁇ by the shake hand according to the same procedure as described in step S 12 ⁇ of FIG. 70. Check that the user public key number of member MX ⁇ is listed in member list 46 ⁇ , and that member MX ⁇ ⁇ is the team master of team ⁇ 2 ⁇ ⁇ and is authorized to change submasters Make sure (step ⁇ 32 2). Next, the authority confirmation function 35 ⁇ transfers the team master list 45 ⁇ and the membership list 46 ⁇ to the team data list management device 30 ⁇ ⁇ in the same manner as in step S 13 ⁇ of FIG. 70 ( Step S33 3).
  • the list creator confirmation function 37 # checks the digital signature included in the transferred team master list 45 #. As a result, the list creator confirmation function 37 7 confirms that this team master list 45 5 is legitimate created by the team master member MX ⁇ , and the team master list 45 5 And member squirrels 174 (4) is passed to the list change function 38 (step S34).
  • the list change function 3 8 ⁇ creates a team master list 5 1 ⁇ in which the submaster ⁇ ⁇ ⁇ described in the team master list 4 5 ⁇ has been replaced with the submaster MWC, and uses this digital signature function 3 9 9 (Step S35 ⁇ ).
  • the digital signature function 39 9 obtains the secret key of the team master MX ⁇ from the above-mentioned secret key file, etc., and adds the digital signature of the team master MX ⁇ to the member list 51 1.
  • the team master list 52 and the member list 46 are returned to the team data list storage unit 31 (step S37).
  • the authority confirmation function 35 5 stores the contents of the transferred team master list 52 2 and member list 46 6 in the same manner as in step S18 ⁇ in Fig. 70. Verify according to the procedure. In this case, the digital signers of the team master list 52 2 and the member list 46 ⁇ are both team master MX ⁇ , so their legitimacy can be understood.
  • the authority confirmation function 35 5 stops processing without updating the team master list and the member list (step ⁇ 38 8). .
  • the submaster in the team master list has been changed.
  • the original digital signature of the member list 46 ⁇ was that of the team master MX ⁇ , but there is no problem if this is the digital signature of the submaster MY ⁇ .
  • the team master MX ⁇ who has the authority to change the submaster can always give his / her digital signature to the member list 46 ⁇ . Therefore, in this case, the digital data of the submaster MY ⁇ is read from the member list 46 ⁇ on the team data list management device 30 side.
  • the team master list 45 5 stored in the team data list storage device 31 ⁇ is the same as that shown in Fig. 70 or 72, and the member list 48 8 is shown in Fig. 70. It is the same as the one after the member change.
  • the list creator confirmation function 37 ⁇ is as shown in FIG.
  • Step S41 1 the authority confirmation function 35 5 authenticates the member MX ⁇ ⁇ ⁇ by the shake hand according to the same procedure as described in step S 12 ⁇ of FIG. 70. Confirm that the user public key number of the member MX is in the member list 48, and that the member MX is the team master of the team 2 and has the reference authority for the requested list. Check that is given (step S42 4). 176
  • the authority confirmation function 35 5 is executed in the same way as in step S13 ⁇ in Fig. 70 by using the team master list 45 5 and the member list 48 8 regarding the specified team ⁇ 2 ⁇ as the team data list.
  • the data is transferred to the management device 30 (step S43).
  • the authority confirmation function 35 ⁇ saves the team master list 45 ⁇ for use in the authority confirmation performed later.
  • the list creator confirmation function 37 # examines the digital signatures of the transferred team master list 45 # and member list 48 #, and each of them checks the digital signature. Confirm that they are legitimate ones created by the team masters MX ⁇ and submaster MY ⁇ included in the team master list 45 ⁇ (step ⁇ 44 4).
  • the list creator confirmation function passes the transferred two lists to the list change function 38 8.
  • the digital signature function 39 9 obtains the secret key of the team master MX ⁇ from the above-mentioned secret key file, etc., and attaches the digital signature of the team master MX ⁇ to the team master list 55 5 and the member list 56 ⁇ ⁇ ⁇ ⁇ , respectively.
  • the created team master list 57 7 and member list 58 ⁇ ⁇ are created and returned to the team data list storage device 31 1 (step ⁇ 46 6).
  • the authority confirmation function 3 5 ⁇ is composed of the transferred two lists and the team master list 4 5 ⁇ ⁇ ⁇ stored in the previous step S 4 3 ⁇ (that is, Old team master list)
  • the authority is confirmed in accordance with the flowchart shown in FIG. 74 (step S47 ⁇ ).
  • FIG. 75 shows a state of the team master list member list which is compared and collated in each step of FIG. 74 when such authority confirmation is performed.
  • the authority confirmation function 35 ⁇ obtains the team master lists 57 ⁇ and 45 ⁇ ⁇ ⁇ as the new and old team master lists, respectively, and obtains the member list 58 ⁇ as the new member list (step S 6). 1)).
  • the authority confirmation function 35 ⁇ checks the digital signatures of the team master list 57 7 and the member list 58 8, respectively (step ⁇ 62 2). If any of them has been tampered with, these two lists are transferred from the team data list management device 30 (client CL) to the team data list storage device 31 (server SVC).
  • Authority check function 35 5 ⁇ stops the process of changing the team master because a fraudulent activity occurred during the process.
  • the authority checking function 35 5 checks the digital signature of the new team master list 57 7 and finds the digital signature of the old team master list 4. 5 Confirm that the digital signature is from the same team master ⁇ ⁇ ⁇ as the digital signer (Step S 63 ⁇ ) c. This is to confirm that the authority has been delegated from the person who was originally the team master If the result of the determination in step S63 ⁇ becomes "NO", it is considered that there is an illegal act due to a violation of authority or the like, and the process of changing the team master is stopped.
  • step S64 it is checked whether the digital signer of the new team master list 57 ⁇ has master authority (step S64). For example, in the member change described in Fig. 70 described above, the digital signature of the team master list 45 ⁇ is obtained by the member MX ⁇ ⁇ ⁇ who has master authority, which means that the team The same applies to master 52 5 (that is, if the determination result of step ⁇ 64 4 is “YES”). On the other hand, in the case where the team master itself is changed, the processing time of step S47 ⁇ in FIG.
  • step S64 corresponds to the transition period in which the authority is delegated from the member MX ⁇ to the member ⁇ ⁇ , and the team master list is changed.
  • 57 7 is in a transitional state where the new administrator member ⁇ ⁇ is the master and the old administrator member MX ⁇ ⁇ ⁇ ⁇ is digitally signed, and the digital signer of the team master list 57 ⁇ is the master. Looks like you don't have star power. If such a state is detected and the change of the team master itself is recognized (judgment result in step S64 "is“ NO ”), the authority confirmation function 35 5 checks the digital signature of the new member list 58 8.
  • step ⁇ 65 5 The power that the digital signature is included in the new Team Master List 57 ⁇ , or is it the digital signer of either the new or old Team Master List 57 7 or 45 4? Check if (step ⁇ 65 5). If none of the conditions is satisfied, it is considered that an illegal act such as tampering has occurred, and the authority confirmation function 35 ⁇ stops the team master change process. Furthermore, in this case, since the digital signer of the member list 58 8 is the same as the digital signer of the new and old team master lists 57 7 and 45 5, the authority confirmation function 35 5 requires the formal procedure. It can be determined that the member list has been created. Through the processing of steps S62 2 to ⁇ 65 5 described above, the team master MX with proper authority can perform team operations in a normal operation.
  • the authority confirmation function 35 # sends the new and old team master lists 57 #, 45 # and the membership list 58 # to the team data list management device 30 # (step S48). Subsequent processing is performed under the direction of the new team master MK ⁇ , and the digital signature of the team master list 57 7 and member list 58 8 is written with the digital signature of the team master M M. This is the process for replacement.
  • the list creator confirmation function 57 7 confirms the digital signature included in each transferred list (step ⁇ 49 9).
  • the list creator confirmation function 37 7 confirms that the digital signatures of the old team master list 45 5 and the new member list 58 8 have not been altered, and then the new and old team master list 5 7 Check whether the digital signatures of 7 ⁇ and 45 5 match each other, and further, based on the contents of the old team master list 45 ⁇ , member MX ⁇ who is the digital signer of the list is assigned to the team. Check if you have master authority. In this case, since all three conditions described above are satisfied, the list creator confirmation function 37 ⁇ changes the team master list 57 7 and the member list 58 ⁇ ⁇ to the list change function 3 8 Hand over to ⁇ .
  • the list change function 38 8 creates a team master list 59 9 and a member list 60 ⁇ based on the team master list 57 7 and the member list 58 ⁇ , and creates a digital signature function 39 9. Pass to.
  • the digital signature function 39 ⁇ obtains the private key for member ⁇ ⁇ ⁇ from the above-mentioned private key file and attaches the digital signature of member ⁇ ⁇ to each of the team master list 59 ⁇ and member list 60 ⁇ ⁇ ⁇ . Create a team master list 61 1 and a member list 62 2 and return these lists to the team data list storage device 31 3 180 steps S50 ⁇ ).
  • authorization check function 3 5 zeta authority in accordance with the processing procedure shown in FIG. 7 4 against team master list 6 1 zeta and Menbarisu DOO 6 2 zeta which is transferred Check it (Step S51).
  • the digital signers of these two lists are all team master MKs, it can be determined that these two lists are both valid.
  • the determination result in step S64 6 in FIG. 74 is “YES”.
  • the authority confirmation function 35 ⁇ stops the processing without updating the team master list and the member list. This means that the team master itself has been changed.
  • the team data list management device 30 ⁇ and the team data list storage device 31 1 are member-listed.
  • the list creator checks the team data list management device 30 ⁇ and the team data list storage device 31 1 as follows. Is performed. First, when there is a member list reference request from the team data list management device 30 ⁇ , the team data list storage device 31 1 reads the old team master list 45 5 and the new member list 58 8 from the team data list. Transfer to management device 30 #.
  • the list creator confirmation function 37 7 confirms whether the digital signatures of the two transferred lists have been tampered with, and then checks the old team master list 4 5 Based on the contents of ⁇ , the digital signer of the list (member MX ⁇ in Fig. 73) Check that you have the required permissions. On the other hand, if there is a member list change request or a master change request from the team data list management device 30 #, the team data list storage device 31 # will store the new and old team master lists 57, 45 5 and the new Transfer the member list 58 8 to the team data list management device 30 ⁇ .
  • the list creator confirmation function 37 checks whether the digital signatures of the two transferred lists have been tampered with. Confirm. Next, the list creator confirmation function 37 ⁇ compares the digital signatures of the new and old team master lists 57 7 and 45 5 with each other to confirm whether they match. Next, the list creator confirmation function 37 7 confirms whether the digital signer of the old team master list 45 ⁇ has team master authority, as in the case of the membership reference request.
  • each time the team data list is used the user needs to confirm on the client CL side whether the team master is genuinely genuine.
  • the user needs to confirm on the client CL side whether the team master is genuinely genuine.
  • the display of the computer that composes the team data list management device 30 # "This list is normally managed by the following members as an administrator. Name: Member MX #, organization : Mitsubishi Materials Corporation.
  • the following functions are added as new functions that cooperate with the list creator confirmation function 37 7, or are combined as a function of the list creator confirmation function 37 7. 182 The problem is solved.
  • the public key of the team master is registered in advance, for example, in the public key database 41 (see FIG. 66) on the client CL ⁇ side for each team, and the public key management function 40 ⁇ is registered in the public key database 41.
  • the public key database 41 (see FIG. 66) on the client CL ⁇ side for each team, and the public key management function 40 ⁇ is registered in the public key database 41.
  • a serial number or the like for identifying the public key is registered in the public key database 41 as information on the public key, and the public key management function 40 stores the serial number in the public key database 41.
  • the list creator confirmation function 3 7 uses the team master's public key notified from the public key management function 40 ⁇ instead of sending the above-mentioned message on the computer display.
  • the list creator confirmation function 37 ⁇ uses the team master's public key notified from the public key management function 40 ⁇ instead of sending the above-mentioned message on the computer display.
  • the public key of member MX ⁇ who is the former administrator should no longer be used. Can not be done. Therefore, the public key of the team master registered on the client 183 need to change automatically.
  • the following process should be performed after the final team master list 61 ⁇ (see FIG. 73) is created (that is, after step S51 ⁇ ). Good.
  • the authority confirmation function 35 ⁇ is replaced with the old team master list, the transitional team master list, and the final team master list (that is, the team master list 45 ⁇ ).
  • the list creator confirmation function 37 ⁇ registers the member MX ⁇ ⁇ ⁇ as the team master in the public key database 41 ⁇ through the public key management function 40 ⁇ . Know that you are.
  • the list creator confirmation function 37 ⁇ is based on the three lists transferred from the team data list storage device 31 ⁇ . It can be confirmed that authority has been delegated to the barrel member ⁇ ⁇ ⁇ .
  • the team masters registered in the team master lists 45 ⁇ , 57 ⁇ , and 61 ⁇ respectively transition from member MX ⁇ to member ⁇ ⁇ ⁇ ⁇ ⁇ to member ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ .
  • the list creator confirmation function 37 7 uses the public key management function 40 ⁇ to interrogate the public key of the person registered as the team master in the public key database 41 1 from the member MX ⁇ . Change to member ⁇ ⁇ ⁇ . Since the change of the team master is not so complicated, the user may be asked to confirm the change when performing the change process. In addition, various information other than the public key can be used for confirming the team master. 184
  • the team data list management program consists of (1) members who notify the information for identifying and authenticating the instructor who issues the change instruction to a predetermined request destination and share resources with each other.
  • a digital signature is created, and the computer performs a digital signature process in which the digital signature is attached to the team data list changed in the list change process and sent to the request destination.
  • the above-mentioned team data list management program may further comprise: at least one member list including at least member information on the member and a digital signature of the master; master information indicating authority of the master; The master A master list containing at least 185 digital signatures is used as the team data list.
  • the master includes a team master having a right to change the master list
  • the change instruction is a change instruction of the team master
  • the confirmation processing is Transmitting the changed member list and master list to the request destination; and transmitting the changed member list and master list included in the transition period member list and the transition period master list returned from the request destination in response to the process.
  • the digital signature processing further includes a process of creating a digital signature of the team master after the change specified by the change instruction, Sending back the new member list and the new master list with the digital signature to the master list in the transition period to the request destination. It may have.
  • the above-described team data list management program includes a process of acquiring identification information for identifying the team master from a predetermined location and registering the identification information in advance, the identification information of the team master and the request destination. A process of confirming whether or not the digital signature of the master is the digital signature of the team master based on the digital signature of the master included in the member list and the master list transmitted from the master list.
  • the program may be executed by a computer.
  • the above-mentioned team data list management program is configured so that, based on the master list acquired at the time of the change instruction, the transition of the master list during the transition period and the transition of the contents of the new master list, the team master A process of confirming that the change has been made through a formal procedure; and if the change has been confirmed, acquiring the identification information of the changed team master specified in the change instruction, and registering in advance with the identification information.
  • To update the identified team master identification information before the change 186 may be further executed by a computer.
  • the team data storage program includes: (1) information relating to a team composed of members sharing resources with each other and a master having management authority for the information; (2) When a reference request is sent from a predetermined request source, a storage process for storing in advance a team data list prepared according to the authority of members belonging to the team.
  • the storage processing may include a step of storing in advance one or more member lists including at least member information regarding the members and a digital signature of the master.
  • the computer may execute a process of storing in advance master information indicating the authority of the master and a master list including at least the digital signature of the master.
  • the master includes a team master having an authority to change the master list, and the authority confirmation processing is performed by the instructor from the request source to the team master.
  • the master list before the change is saved as the old master list 187, and sends the master list and the membership list to the request source in response to a request from the request source, and, out of these lists, the master list in the transition period in which information on the team master is changed.
  • New master to which the digital signature of the changed team master specified in the change instruction is attached to these lists Receiving the list and the new member list from the request source and confirming the validity, and updating the stored member list and the stored master list only when the validity is confirmed. It is good even if it causes the computer to further execute the processing.
  • the invention of the sixth embodiment has the following effects.
  • a team data list such as a master list and a member list stored in a server or the like is obtained, and these lists are acquired by the master having authority. After confirming that the list is created properly, the list is modified and returned to the request destination. From this, it is possible to detect that unauthorized members, such as general members other than the master, server administrators, crackers, etc., have manipulated the team data list.
  • the team master itself can change the team master, an administrator such as a server storing the team data list is required. 188 Delegate authority of team master without intervention.
  • a system in which a plurality of managers manage the team data list can be realized, it is possible to reduce the burden on a small number of managers.
  • the digital signature of the master is included in the team data list, it is possible to detect an illegal act such as falsification performed on the team data list.
  • the authority check is performed to determine whether or not the instructing person who made these requests has the authority. It is possible to prevent unauthorized acts by unauthorized persons.
  • information for identifying and authenticating the team master such as a public key
  • the team master is changed.
  • the public key of the registered team master is updated as appropriate. For this reason, each time the team data list is operated, the user himself / herself does not need to visually confirm the team master, and the troublesome work of the user becomes unnecessary, and the approval of the team master can be automatically performed.
  • the “computer system” includes an OS and hardware such as peripheral devices.
  • the “computer-readable recording medium” refers to a general-purpose medium such as a floppy disk, a magneto-optical disk, a ROM, a CD-ROM, and a storage device such as a hard disk incorporated in a computer system.
  • a “computer-readable recording medium” is a dynamic medium for a short time, such as a communication line for transmitting a program through a network such as the Internet or a communication line such as a telephone line.
  • One that holds the program transmission medium, transmission wave
  • server / client In that case This includes programs that hold programs for a certain period of time, such as volatile memory inside a computer system.
  • the above-mentioned program may be for realizing a part of the above-mentioned functions, and may be for realizing the above-mentioned functions in combination with a program already recorded in the computer system. Is also good.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Description

明細 :
情報共有 技術分野
本発明は、 複数のユーザ間での情報共有を目的とし、 情報の視き見や改 竄を防ぐための情報共有システムおよびその情報処理方法、 並びに記録媒 体に関するものである。 背景技術
近年のコンピュータ ' ネッ 卜ワーク技術の発展に ί半い、 様々なデジタル 情報がコンビュ一タネッ 卜ヮ一ク上で利用されるようになった。
しかし、 これらのデジタル情報は、 コンピュータ上や、 ネッ トワーク上 では、 他人の視き見や改竄が容易である。
そこで、 特に秘匿の必要があるユーザのプライべ一卜情報やビジネス情 報などは、 暗号化技術を利用して暗号化した後、 取得、 伝達、 加工、 記録 する必要がある。
このような秘匿する必要のある情報を暗号化するために、 データ暗号規 格 （D E S ： Data Encryption Standard) などの共通鍵喑号方式が開発 された。
この方式では、 データを暗号化する暗号鍵をユーザ間で共有するため、 他のユーザに暗号鍵が取得されないように、配送、記録する必要があった。 そのため、 この喑号鍵を視き見や改竄、取得されないようにするために、 暗号鍵を別の鍵でさらに暗号化した状態の鍵である暗号化鍵と して配送す る部が提案されている。
ある情報を共有したい複数のユーザがいる場合に、 上記の手法で情報を 暗号化するには、 これらの暗号鍵や暗号鍵を暗号化するための鍵を管理す る鍵管理システムや、 情報を共有するュ一ザをグループ化して管理するグ ループ管理サーバ、 情報へのアクセス制御部などを利用する必要がある。 このように特定グループで秘匿データを共有する場合の共通鍵管理は、 サーバで行われ、 このサーバにはサーバ管理者が設けられる。
ところが、このサーバ管理者が当該特定グループに含まれない場合には、 何の障害もなくデータを司見くことができることになる。
また、 サーバ管理者が当該特定グループに含まれたとしても、 一存でグ ループメンバーを変更することができ、 データの管理上、 万全であるとは いえない。 発明の開示
それゆえ、本発明の目的の一は、暗号化情報を保管するデータベースや、 サーバ、 ファイルシステム等の管理者による情報の内容の視き見や改ざん を防止できる情報共有システムおよびその情報処理方法、 並びに記録媒体 を提供することにある。
当該発明によれば、 その目的は、 共通鍵暗号化方式および公開鍵暗号方 式を採用し、 少なく ともグループで共通鍵を共有可能な情報共有システム であって、 少なく とも複数のメンバ一でアクセス可能で、 少なく ともチ —ムマスタ一のデジタル署名、メンバ一公開鍵情報を含むメンバーリス ト、 暗号化鍵情報を含む共通鍵リス ト、 および暗号化データを保管可能な情報 保管装置と、 情報を見てもよい少なく とも一のメンバーの公開鍵を記憶 する記憶部と、 情報を暗号化するための共通鍵を用いる上記共通鍵暗号化 方式に基づいて入力情報を暗号化して暗号化データを生成する暗号化部と、 暗号化に用いた共通鍵を、 上記記憶部に記憶され指定された公開鍵で暗号 化し、 暗号化鍵を生成する暗号化鍵生成部と、 上記複数の暗号化鍵および 暗号化データを上記情報保管装置に転送する転送部と、 上記情報保管装置 からメ ンバーリス トを取得して、 当該メンバ一リス 卜のチームマスタ一の デジタル署名が指定されたデジタル署名と一致するか否かを判断し、 一致 する場合にのみ追加するメンバーの公開鍵の登録または脱会するメンバー の公開鍵の削除を行い、 追加登録または削除の場合、 少なく ともチームマ スターのデジタル署名、 メ ンバ一公開鍵情報を含む新メンバーリ ス トを作 成して上記情報保管装置に転送するリス ト管理部と、 上記情報保管装置か ら所望の暗号化鍵情報および暗号化データを取得して、 この暗号化鍵情報 から共通鍵を復号し、 復号した共通鍵で取得した暗号化データを復号する 復号化部とを有する暗号化復号化装置と を備えた情報共有システムとい う装置により達せられる。
当該発明によれば、 グループで共有鍵を共有することができ、 暗号化デ —タを保管するデータベースや、 サーバ、 ファイルシステムの管理者に情 報の内容を見られてしまう可能性もない。 また、 当該発明によれば、 その目的は、 送信者側に設置された送信者側 端末と、 前記送信者側端末とネッ トワークを介して接続され受信者側に設 置された受信者側端末とを有し、 該送信者側端末と受信者側端末との間で 情報の送受信を行い、該情報の改竄を検知する情報改竄検知装置において、 前記受信者側端末が前記情報を受信したことを確認した旨を表す受信内容 確認情報を作成する受信内容確認情報作成部と、 前記受信内容確認情報を 前記ネッ トワークを介して送信する送信部と、 前記ネッ トワークを介して 前記受信内容確認情報を受信する受信部と、 前記送信者側端末から送信さ れる前記情報と前記受信内容確認情報とを比較し、 この比較結果に基づい て改竄を検知する改竄検知部とを具備する情報改竄検知装置という装置に より達せられる。
当該発明によれば、 発明によれば、 受信内容確認情報、 送信内容確認情 報を用いて改竄検知を行うように構成したので、 受信した情報を復号化す る権利を有しない端末であっても、 情報の改竄を検知することができる。 また、 当該発明によれば、 その目的は、 鍵暗号化部と、 暗号化部とから なる暗号化装置において、 前記鍵暗号化部は、 共通鍵暗号方式を利用して 暗号化に用いる共通鍵を取得または生成する共通鍵取得部と、 公開鍵暗号 方式を利用して前記共通鍵を暗号化し暗号化鍵とする共通鍵暗号化部と、 前記共通鍵より共通鍵改竄検出に利用する鍵情報を作成する第 1共通鍵改 竄検出情報作成部とからなり、 前記暗号化部は、 前記共通鍵を用いて平文 を暗号化し暗号文とするデータ暗号化部と、 前記平文より第 1データ改竄 検出情報を作成する第 1データ改竄検出情報作成部とからなる暗号化装置 という装置により達せられる。
当該発明によれば平文毎に改竄検出情報を作成することはせず、 各平文 を暗号化する共通鍵に対して改竄検出情報となる鍵情報を作成し、 改竄検 出と共通鍵作成者の本人確認を可能としたので、 情報を暗号化した暗号化 情報のォ一バーヘッ ドを減少させることができる。 したがって、 暗号化情 報の転送時におけるネッ トワークにかかる負荷と暗号化情報を保管する際 に要する記憶装置の容量を減少させることができる。 また、 当該発明によれば、 その目的は、 チームを階層化するためのチー ムデ一タリス トを管理するチームデータリスト管理装置であって、 所定の 要求先に前記チームデータリス トの操作要求を行い、該操作要求に応じて、 操作対象のチームからルートチームに至る各チームについて、 自チームの 親チームを表す識別子及び前記親チームの管理者のデジタル署名を含むォ —ソリティデータと、 自チームの管理下にあるサブチームの管理権限者に 関する管理者情報及び自チームの管理者であるチームマスタ又は前記親チ —ムの管理者のデジタル署名を含むォーソリティ リス トを有するチームデ —タ リス 卜を前記要求先から取得し、 前記識別子を用いて取得されたチー ムを前記ル一トチームまで迪りながら各チームについて、 前記チ一ムデー タリス 卜のデジタル署名が改竄されていないこと及び前記管理者情報を用 いて権限を持つ者によるデジタル署名であることを確認して、 ユーザによ る前記ル一トチームのチームマスタの承認を確認する正当性確認部と、 該 正当性確認部によって正当性が確認された前記チームデータリス 卜に対し て前記操作要求に応じた変更を加えるチームデータリス ト変更部と、 前記 操作要求を行った指示者のデジタル署名を作成し、 前記変更されたチーム デ—タリス トに該デジタル署名を添付して前記要求先に送出するデジタル 署名部とを具備するチームデータリスト管理装置という装置により達せら れる。
当該発明によれば、 ォーソリティ リス トとォーソリティデータの含まれ たチームデータリ ス トを用いることで各チームの下にサブチームを作成す ることができ、 階層化されたチームを構築することができる。
また、 当該発明によれば、 その目的は、 送信する情報を暗号化した暗号 化情報を含む暗号情報を作成する暗号情報作成装置と、 同報通信の被配信 メンバ一の公開鍵が含まれるメンバーリ ス トを管理するメンバ一リス ト管 理装置と、 前記暗号化情報を復号化する暗号情報復号化装置と、 前記暗号 情報作成装置より送信された暗号情報を受信し、 該喑号情報を前記メンバ —リス トをもとに 1以上の前記暗号情報複号化装置に配信する情報中継装 置と、 からなる同報通信システムにおけるメンバ一リス ト管理装置であつ て、 同報通信を行う 1以上のメンバーの公開鍵を含むメンパーリス トを 作成するリス ト作成部と、 前記公開鍵を取得し保存する公開鍵管理部とを 備えるメンバ一リス ト管理装置という装置により達せられる。
当該発明によれば、 情報中継装置において暗号化された情報を複号化し ない仕組みとしたので、 情報中継装置の管理者による同報通信の通信内容 の漏洩や改竄等の不正を防ぎ、 本当に情報を共有する必要のあるメンバー にだけ同報通信内容を共有することができる。 また、 当該発明によれば、 その目的は、 変更指示を行う指示者の本人識 別 ·認証を行うための情報を所定の要求先に通知して、 資源を互いに共有 するメンバで構成されるチームに関わる情報と該情報の管理権限を有する マスタのデジタル署名とが含まれ、 チームに属するメンバの権限に応じて 用意されたチームデータリス 卜を前記要求先から取得し、 取得された該チ —ムデータ リ ス トの内容に基づいて、 権限を持つマスタが前記チームデー タ リス トを作成したか否かを確認するリス ト作成者確認部と、 該権限を持 つマスタの作成であることが確認された前記チームデータリス トに対して 前記変更指示に応じた変更を加えるリス ト変更部と、 前記指示者のデジタ ル署名を作成し、 前記リス ト変更部で変更されたチームデータリス トに該 デジタル署名を添付して前記要求先に送るデジタル署名部とを具備するチ ームデータリス 卜管理装置という装置により達せられる。
当該発明によれば、 正当な権限を持つマスタからの変更指示に応じて、 サーバ等に保管されているマスタ リス ト及びメ ンバリス ト等のチームデー タリス トを取得し、 これらリス トが権限を持つマスタによって正当に作成 されたことを確認した後に、 これらリス 卜に変更を加えて要求先へ返すよ うにしている。 こ う したことから、 マスタ以外の一般のメンバ， サーバの 管理者， クラッカ等の正当な権限を持たない者がチームデータリス トを不 正に操作したことを検知できる。 図面の簡単な説明
図 1は、 第 1の実施形態の発明に係る情報共有システムの基本的な構成 図である。
図 2は、 第 1の実施形態の発明に係る暗号化複号化装置の構成例を示す ブロック図である。
図 3は、 図 2の復号化部の構成例を示す図である。
図 4は、 WWWサーバの保管される各種リス 卜を示す図である。
図 5は、 第 1の実施形態の発明に係る情報管理装置としての WWWサ一 バにおける D B M Sの詳細な機能を説明するための図である。
図 6は、 グループで共通鍵を共有する場合であって、 グループへの公開 鍵 I Dの登録動作例を説明するための図である。
図 7は、 グループで共通鍵を共有する場合であって、 共通鍵の登録動作 例を説明するための図である。
図 8は、 グループで共通鍵を共有する場合であって、 データを暗号化す る場合の動作例を説明するための図である。
図 9は、 共有したいユーザを別途してする場合であって、 データを喑号 化する場合動作例を説明するための図である。
図 1 0は、 復号化動作例を説明するための図である。
図 1 1は、 第 2の実施形態の発明の一実施形態による情報改竄検知装置 の動作原理を説明するプロック図である。
図 1 2は、 同一実施形態による情報改竄検知装置の構成を示すブロック 図である。
図 1 3は、 図 1 2に示す受信内容確認情報確認部 1 0 3 /3の動作を説 明するフローチヤ一トである。
図 1 4は、 図 1 2に示す送信内容確認情報作成部 1 0 4 /3の動作を説明 するフローチヤ一トである。
図 1 5は、 図 1 2に示す受信内容確認情報作成部 2 0 2 j3の動作を説明 するフローチヤ一トである。 図 1 6は、 図 1 2に示す送信内容確認情報確認部 2 0 5 の動作を説明 するフローチヤ一トである。
図 1 7は、 従来の情報改竄検知装置の動作原理を説明する図である。 図 1 8は、 従来の情報改竄検知装置の欠点を説明する図である。
図 1 9は、 第 3— 1〜第 3— 3の実施形態の発明の一実施形態である喑 号化複号化装置の構成を示すプロック図である。
図 2 0は、 第 3— 1〜第 3— 3の実施形態の発明の一利用形態を示す図 である。
図 2 1は、 暗号化に係る動作を説明するフローチヤ一卜である 図 2 2は、 暗号化前の情報と暗号化情報の構成を示す図である- 図 2 3は、 複号化に係る動作を説明するフローチヤ一卜である- 図 2 4は、 暗号化情報に情報を追加する際の動作を説明するフローチ ャ一 トである。
図 2 5は、 暗号化情報に情報を追加する前後の暗号化情報の構成を示す 図である。
図 2 6は、 共有メンバ一 Βが、 チームに共有メンバ一 Cを追加する際の 動作を説明するフ口一チヤ一トである。
図 2 7は、 チームに共有メンバ一 Cを追加する前後の暗号化情報の構成 を示す図である。
図 2 8は、 チームから共有メンバーを削除する際の動作を説明するフロ —チヤ一トである。
図 2 9は、 チームから共有メンバー Αを削除する前後の暗号化情報の構 成を示す図である。
図 3 0は、 第 3— 1の実施例における情報保管装置に記憶されている情 報を示す図である。
図 3 1は、 第 3— 2の実施例において情報を追加した際の情報保管装置 に記憶されている情報を示す図である。
図 3 2は、 第 3— 3の実施例において復号化後のスケジュールの表示例を示 す図である。
図 3 3は、 従来の暗号化 ·デジタル署名方式における暗号化の動作を説明す るフローチヤ一トである。
図 3 4は、 従来の暗号化 ·デジタル署名方式における復号化の動作を説明す るフ口一チヤ一卜である。
図 3 5は、 特開平 8— 1 5 6 9 6 4に開示されている暗号化方式による暗号 化前の情報と暗号化情報の構成を示す図である。
図 3 6は、 特開平 9— 7 1 3 8 8に開示されている暗号化方式による暗号化 前の情報と暗号化情報の構成を示す図である。
図 3 7は、 第 4一 1実施形態によるチームデータリスト管理装置及びチーム デ一夕リスト保管装置を有するシステムの構成を示したプロック図である。 図 3 8 A， B , C， Dは、 第 4一 1実施形態において、 チームデータリスト 保管装置が設置されたサーバ側に記憶されるチームデ一夕リストの構造を示し た説明図である。
図 3 9は、 第 4一 1実施形態におけるチームの階層の一例を示した説明図で ある。
図 4 0は、 図 3 9に示すチーム階層の各チームについてチームデ一夕リスト の具体的な値を記入した説明図である。
図 4 1は、 第 4 - 1実施形態においてサブチームを作成するための処理手順 を示した説明図である。
図において （A) は、 メンバ Cによるサブチーム作成要求 （チーム 1 0 1の 下に、 チームマス夕を Xとして、 サブチーム 1 0 3 δを作成） を意味し、 S 1 1 6〜S 1 5 δの意味するところは、 各々次の通りである。
S 1 1 δ ：サブチーム作成要求
5 1 2 δ ：データリスト管理装置 3 0 δは、 チーム 1 0 1 δに関する
情報（他の 1 0 1 δのサブチームの情報などを含む）を取得
5 1 3 δ： AUD δ、 A U L δを作成
5 1 4 δ ：新規に作成した 1 0 3 δの AUD <5、 AU L δを転送 （1
0 3 <5の八110 (5、 A U L S保存要求）
5 1 5 ό ：チ一ム 1 0 1 5の AU D δと AU L δを調べる。 Cは、 サ
ブチーム作成権限者に選ばれているので、 正当な権限を持
差替え用紙 （規則 26) y/i
つものによる作成要求と判断し. 1 0 3 (5の A UD δと A U L 0を保管
また図において （B ) は、 メンバ Xによるチーム 1 0 3 δの管理要求を意味 し、 S 1 6 <5〜S 1 9 (5の意味するところは、 各々次の通りである。
5 1 6 δ ：チーム 1 0 3 δのリスト要求
5 1 7 δ ：チーム 1 0 1 <5、 1 0 3 δの A U D δと AU L δを転送
5 1 8 6 ： 2つのリストは、 親チーム 1 0 1 δのチームマス夕によつ て指名された Cによって、 ち一む 1 0 3 δが作成されてい るので、 Xは、 そのリストが正常な状態で取得しているこ とがわかる
5 1 9 δ ： Xは、 チーム 1 0 1 δのオーソリティリストを作成
また図において （C) は、 メンバ Xによるサブチーム作成権限者 （s u b AU δ ) としての Wと Vの指定を意味し、 S 2 0 5〜S 2 1 <5の意味すると ころは、 各々次の通りである。
S 2 0 δ ：更新された 1 0 3 <5の AUD δと AU L δを転送 （1 0 3 δの AUD S、 AU L δ保存更新要求）
S 2 1 δ ：サーバ S V側に保管されているリストにより、 Xが間違い なく、 Αによる管理体系の中で正当に 1 0 3 (5のチームマ ス夕として任命されていることを検証できる
図 4 2は、 図 4 1の処理過程でサブチーム作成要求時に行われるサーバ側の 権限確認機能についてその処理手順を示した説明図である。
図 4 3は、 図 4 1の処理過程で実施されるクライアント側のリスト正当
差替え用紙 （規貝 IJ26) 10
正当性検証に関わる処理手順を示した説明図である。
図 44は、 図 41の処理過程において、 クライアント側で新規に作成したチーム データリストをサーバ側で権限確認を行う際の処理手順を示す説明図である。
図 45は、 第 4一 1実施形態において、 サブチームのチームマス夕を変更するた めの処理手順を示した説明図である。
図 46は、 第 4一 1実施形態において、 サブオーソリティの作成権限を変更 （削 除） するための処理手順を示した説明図である。
図 47は、 第 4— 1実施形態において、 サブチームを削除するための処理手順を 示した説明図である。
図において （A) は、 メンバ Cによる以前作成した 101 δのサブチーム 103 δの削除を意味し、 S 81 <5〜S 82 δの意味するところは、 各々次の通りである。
S 81 (5 ：命令を転送
S 82 δ ：チーム 101 δ、 103 δの AUD 5、 AUL (5を見ると、
101 (5の s u bAUである Cが 103 (5を作成している
(1036の AUD δに署名している） ことがわかるので 正当な権限で発行された削除命令と判断して、 103 δの
AUD δと AUL δを削除する
また図において （Β) は、 メンバ Αの権限によるチーム 103 δの削除要求を意 味し、 S 83 (5〜S 84 δの意味するところは、 各々次の通りである。
S 83 δ ：命令を転送
S 84 <5 ：チーム 101 δ、 103 δの AUD6、 AUL <5を見ると、
101 <5の ΤΜδである Aが s u bAUとして指名した C が 103 <5を作成している（103 <5の AUD5に署名し
ている）ことがわかるので、 正当な権限で発行された削除
命令と判断して、 103 <5の AUD <5と AUL (5を削除す る
図 48は、 クライアント側に居るユーザの権限確認を行う際にサーバが用いるシ エイク八ンドないしチャレンジレスポンスと呼ばれる手法の手順を示した説明図 である。
図 49は、 第 4— 2実施形態におけるチームの階層の一例を示した説明図である。 図 50は、第 4— 3実施形態におけるチームの階層の一例を示した説明図である。 図 51は、 アクセス制御リストを利用して情報共有を行う従来のシステムの構成
差替え用紙 （規貝 U26) l ox
を示したブロック図である。
図 5 2は、 第 5の実施形態の発明の同報通信システムの仕組みを示す図である。 図 5 3は、 一般的なメンバ一リストの例である。
図 5 4は、 複数のリストで構成されたメンバーリストの一例である。
図 5 5は、 本発明のメンバーリスト管理装置の実施の形態を示す図である。 図 5 6は、 リスト作成部の動作フローチャートである。
差替え用紙 （規則 26) 1 1 図 5 7は、 第 5の実施形態の発明の暗号情報作成装置の実施の形態を示 す図である。
図 5 8は、 第 5の実施形態の発明の同報通信システムにおける暗号化復 号化過程を示す図である。
図 5 9は、 第 5の実施形態の発明の同報通信システムにおける複数パ一 ッ送信および複数パーッ受信の仕組みを説明する図である。
図 6 0は、 第 5の実施形態の発明の暗号情報復号化装置の実施の形態を 示す図である。
図 6 1は、 第 5の実施形態の発明の情報中継装置の実施の形態を示す図 である。
図 6 2は、 第 5の実施形態の発明の同報通信システムを証券ニュース配 信システムとして応用した実施例である。
図 6 3は、 メーリングリス トサーバを利用した本発明の同報通信システ ムの 1実施例である。
図 6 4は、 従来の同報通信システムの仕組みを説明する図である。 図 6 5は、 特開平 7— 2 4 5 6 0 5に開示されている同報通信システム の仕組みを説明する図である。
図 6 6は、 第 6の実施形態の発明の一実施形態によるチームデータリス ト管理装置及びチームデータリス ト保管装置を有するシステムの構成を示 したブロック図である。
図 6 7は、 第 6の実施形態の発明の前提となる技術を説明するための第 1の図であって、 メンバリス トの管理機能及び保管機能をクライアントー サーバ間で分割した構成を示したブロック図である。
図 6 8は、 第 6の実施形態の発明の前提となる技術を説明するための第 2の図であって、 クライアント側からサーバ上のメンバリス 卜に含まれて いるメンバ変更を行う場合の処理手順について示した説明図である。 1 2
図 6 9は、 クライアント側に居るユーザの権限確認を行う際にサーバが用いるシ ェイクハンドないしチャレンジレスポンスと呼ばれる手法の手順を示した説明図 である。
図 7 0は、 上記実施形態において、 複数の管理者によってメンバを管理して場合 のメンバ変更に関する処理手順を示した説明図である。
図 7 1は、 同実施形態において、 クライアント側で行われるリスト作成者確認の 処理手順を示したフローチャートである。
図 7 2は、 同実施形態において、 複数の管理者によってメンバを管理して場合の サブマス夕変更に関する処理手順を示した説明図である。
図 7 3は、 同実施形態において、 複数の管理者によってメンバを管理して場合の チームマス夕変更に関する処理手順を示した説明図である。
図 7 4は、 同実施形態において、 図 7 3に示すチームマス夕変更時にサーバ側で 行われる権限確認の処理手順を示したフローチャートである。
図において S 6 1 ζ〜S 6 5 ζの意味するところは、 各々次の通りである。
S 6 1 ζ ：新 ·旧チームマス夕リスト、 新メンバリス卜の取得
S 6 2 ζ ： 2つのリストのデジタル署名確認：改竄されていないか？ (このとき S 6 2 (N O) =クライアン卜からサーバ側へ転送中に 不正行為 （改竄等） が発生したため、 処理中止）
S 6 3 ζ ：新チ一ムマス夕リストは、 旧チームマス夕リストのチーム
マス夕によるデジタル署名となっているか？
(このとき S 6 3 ( N O) =不正行為 （改竄等） が発生したため、 処理中止）
S 6 4 ζ ：新チームマスタリストのデジタル署名者は、 マスタ権限を
持っているか？
(このとき S 6 4 (N O) =この時点で、 チームマス夕自身の変更 時と判断できる。 また δ 6 4 ζ (Y E S ) =通常の変更。 ただし、 管理者自身の変更ではない）
S 6 5 ζ ：新メンバリストのデジタル署名者は、 ①新チームのマス夕
リストに含まれているか？もしくは②旧 （新） チームマス 夕リス卜のデジタル署名者であるか？
(このとき S 6 5 (Y E S ) =正当な権限を持つチームマス夕によ つて正常な操作でチームマス夕自身を変更したと判断する。 また S
差替え用紙 （規則 26) 1
6 4 ζ (N O) =不正行為 （改竄等） が発生したため、 処理中止） 図 7 5は、 同実施形態において、 図 7 4に示す権限確認を行う場合に同図の各ス テツプで比較照合されるチームマスタリスト及びメンバリス卜の様子を示した説 明図である。
図 7 6は、 アクセス制御リストを利用して情報共有を行う従来のシステムの構成 を示したブロック図である。
図 7 7は、 特定グループに属するメンバだけで情報を共有するためにクライアン トーサーバ間で行われる処理手順を示した説明図である。 発明を実施するための最良の形態
以下の実施例はクレームにかかる発明を限定するものではない。 また、 目的の達 成のために、 実施例中で説明されている特徴のすべての組み合わせが必ずしも必要 となるものではない。
差替え用紙 （規則 26) 1 3 .
[第 1の実施形態]
第 1の実施形態の発明は、 複数のュ一ザ間での情報共有を目的とし、 情 報の視き見や改竄を防ぐための情報共有システムおよびその情報処理方法、 並びに記録媒体に関するものである。 第 1の実施形態の発明に関し、 従来以下説明する技術が知られている。 近年のコンピュータ .ネッ トワーク技術の発展に伴い、 様々なデジタル 情報がコンピュータネッ トワーク上で利用されるようになった。
しかし、 これらのデジタル情報は、 コンピュータ上や、 ネッ トワーク上 では、 他人の司見き見や改竄が容易である。
そこで、 特に秘匿の必要があるユーザのプライべ一ト情報やビジネス情 報などは、 暗号化技術を利用して暗号化した後、 取得、 伝達、 加工、 記録 する必要がある。 このような秘匿する必要のある情報を暗号化するために、 データ喑号規 格 （D E S ： Data Encryption Standard) などの共通鍵喑号方式が開発 された。
この方式では、 データを暗号化する暗号鍵をユーザ間で共有するため、 他のユーザに喑号鍵が取得されないように、配送、記録する必要があった。 そのため、 この暗号鍵を視き見や改竄、取得されないようにするために、 暗号鍵を別の鍵でさらに暗号化した状態の鍵である暗号化鍵として配送す る方法が提案されている。 ある情報を共有したい複数のユーザがいる場合に、 上記の手法で情報を 暗号化するには、 これらの暗号鍵や暗号鍵を暗号化するための鍵を管理す る鍵管理システムや、 情報を共有するュ一ザをグループ化して管理するグ 1 - ループ管理サーバ、 情報へのアクセス制御部などを利用する必要がある。 このように特定グループで秘匿データを共有する場合の共通鍵管理は、 サーバで行われ、 このサーバにはサーバ管理者が設けられる。
ところが、このサーバ管理者が当該特定グループに含まれない場合には、 何の障害もなくデータを視く ことができることになる。
また、 サーバ管理者が当該特定グループに含まれたとしても、 一存でグ ループメンバーを変更することができ、 データの管理上、 万全であるとは いえない。 本発明は、 かかる事情に鑑みてなされたものであり、 その目的は、 暗号 化情報を保管するデータべ一スゃ、 サーバ、 ファイルシステム等の管理者 による情報の内容の司見き見や改ざんを防止できる情報共有システムおよび その情報処理方法、 並びに記録媒体を提供することにある。 第 1の実施形態の発明によれば、 複数ュ一ザが共有したい情報を秘匿し ておくために、 たとえば共有鍵暗号方式と公開鍵暗号方式が併用される。 入力情報は、 共有鍵暗号方式で、 共通鍵を用いて暗号化される。 また、 本発明によれば、 たとえばネッ トワーク上での情報共有システム が実現される。
このシステムでは、 少なく と も複数のメンバ一でアクセス可能な情報保 管装置に、 少なく ともチームマスターのデジタル署名、 メンバ一公開鍵情 報を含むメンバ一リス ト、 暗号化鍵情報を含む共通鍵リス ト、 および暗号 化データが保管される。 15 グループに属するメンバ一を追加登録する場合、 情報保管装置からメン バーリス 卜が取得され、 取得したメンバーリス 卜のチームマスターのデジ タル署名が指定されたデジタル署名と一致するか否かを判断される。 そして、 一致する場合にのみ、 少なく ともチームマスターのデジタル署 名、 メンバ一公開鍵情報を含む新メンバーリ ス 卜が作成され、 作成された メンバ一リス 卜が情報保管装置に転送され保管される。 また、 グループに属するメンバーで利用する共通鍵を登録する場合、 情 報保管装置からメンバーリス 卜が取得され、 取得したメンバ一リス トのチ —ムマスターのデジタル署名が指定されたデジタル署名と一致するか否か を判断される。
そして、 一致する場合にのみ、 指定されている公開鍵を用いて登録すベ き共通鍵が暗号化され、 暗号化された共通鍵が情報保管装置に転送され保 管される。 また、 共通鍵を用いてデータを暗号化する場合、 情報保管装置の共通鍵 リス 卜から少なく とも暗号化鍵情報が取得され、 この暗号化鍵情報から共 通鍵が復号される。
そして、 復号した共通鍵で共通鍵暗号化方式に基づいて入力情報が暗号 化されて暗号化データが生成され、 暗号化されたデータが情報保管装置に 転送され保管される。 また、 データを復号する場合には、 情報保管装置から所望の暗号化鍵情 報および暗号化デ一タが取得され、 この暗号化鍵情報から共通鍵が復号さ れり。
そして、 復号した共通鍵で取得した暗号化データが復号される。 16
また、 情報保管装置では、 メンバーリス ト変更要求があると、 グループ 管理手段により要求に応じたメンバ一リス 卜の変更が行われる。
また、 共通鍵の登録要求があると、 共通鍵管理部により、 要求のあった 共通鍵がその暗号化鍵情報を含めて登録される。 また、 共通鍵の取得要求 があると、 共通鍵管理部により、 特定グループでの情報共有に最適な共通 鍵が選択されて、 要求先に転送される。
また、 暗号化データの登録要求があると、 暗号化データ管理部により、 暗号化データが当該データの暗号化に用いられた共通鍵情報とともに保管 される。 また、 暗号化データの取得要求があると、 暗号化データ管理部に より、 保管暗号化データおよび共通鍵情報が要求先に転送される。 以下、 第 1 の実施形態を図面に関連付けて詳細に説明する。
図 1は本発明に係る情報共有システムの基本的な構成図、 図 2は本発明 に係る暗号化復号化装置の構成例を示すブロック図である。 本実施形態 （第 1 の実施形態） に係る情報共有システムは、 図 1に示す ように、 図 2に示す暗号化複号化装置 1 0 αが組み込まれた第 1の端末装 置 1および第 2の端末装置 2 ひ 、 並びに暗号化複号化装置 1 0 αで生成さ れたメンバ一リス トや、 共通鍵リス ト、 暗号化データ等を保管するための 情報保管装置としての WWWサーバ 3 αが、 ネッ トワーク （たとえば、 ィ ンターネッ ト） 4 αで接続されて構成されている。 暗号化複号化装置 1 0 ひは、 暗号化部 1 1 α、 共通鍵生成部 1 2 α、 記 憶部 1 3 ひ 、 暗号化鍵生成部 1. 4 α、 付加情報生成部 1 5 ひ 、 転送部 1 6 α、 デジタル署名確認部 1 7 α、 公開鍵管理部 1 8 ひ 、 デジタル署名付加 17 部 1 9 α、 並びに復号化部 2 0 aにより構成されている。
そして、 デジタル署名確認部 1 7 α、 公開鍵管理部 1 8 α、 およびデジ タル署名付加部 1 9 aを主要素としてリス ト管理部が構成される。 暗号化部 1 1 αは、 情報を暗号化するための共通鍵 d k ひまたは WWW サーバ 3 αから読み出した共通鍵 c k αを用いて、 たとえば共有鍵喑号方 式 （たとえば D E S ) により入力情報 Μ ひを暗号化して暗号化データ M ' αを生成し、 生成した暗号化データ Μ ' αを転送部 1 6 αに出力する。 また、 暗号化部 1 1 αは、 グループで共通鍵を共有する場合であって、 データを暗号化する場合に、 特定グループのメンバーリス ト要求、 具体的 にはグループ I Dやユーザ公開鍵 I Dを含むメンバ一リスト要求を WWW サーバ 3 αに対して行う この要求の転送は転送部 1 6 aを介して行われ る。 共通鍵生成部 1 2 ひは、 たとえば乱数発生回路等により構成され、 情報 を暗号化するための共通鍵 d k ひを生成し、 暗号化部 1 1 αおよび暗号化 鍵生成部 1 4 αに出力する。 なお、 共通鍵 d k aは、 たとえば 6 4ビッ ト データとして生成される。 記憶部 1 3 ひは、 たとえばハードディスクにより構成され、 本システム を共有する複数 nのユーザ各々の固有の公開鍵 P K 1 α ， Ρ Κ 2 α , …， Ρ Κ η αがあらかじめ記録されており、 暗号化鍵生成部 1 4 αおよび公開 鍵管理部 1 8 ひ によりアクセスされる。 暗号化鍵生成部 1 4 ひは、 暗号化に用いた共通鍵 d k α (または共通鍵 c k α ) を、 記憶部 1 3 "に記録されているュ一ザの公開鍵を用い、 たと 18 . えば公開鍵暗号方式 （たとえば RS A) に基づいて暗号化し、 1または複 数の暗号化鍵 ΕΚ Ι α, Ε Κ 2 α , …， ΕΚ η αを生成し、 生成した喑号 化鍵 EK 1 ひ ， Ε Κ 2 α , …， Ε Κ η αを転送部 1 6 αに出力する。 また、 暗号化鍵生成部 1 4 αは、 特定グループに属するメンバーだけで 情報を共有したい場合であって、 そのメンバーで利用する共通鍵の登録を 行う場合、 特定グループのメンパーリス 卜要求を WWWサーバ 3 αに対し て行う。 この要求の転送は転送部 1 6 αを介して行われる。 付加情報生成部 1 5ひは、 たとえば共通鍵 d k αのメ ッセ一ジダイジェ スト k m dひをハツシュ関数などで生成し、 付加情報 a j f ひとして転送 部 1 6 αに出力する。
なお、 付加情報としては、 ユーザの秘密鍵で複号化できる暗号化鍵を特 定するための、 I D、 ユーザパスワード、 証明書、 電子メールア ドレス、 公開鍵、 順序情報のうちの、 いずれか、 もしくは、 複数組み合わせた情報 であってもよレヽ。 転送部 1 6 αは、 入力情報 Μひの暗号化に伴って生成された 1または複 数の暗号化鍵 ΕΚ 1 α, Ε 2 α , …， Ε Κ η α、 暗号化データ Μ ' ひ 、 および付加情報 a j f αをネッ トワーク 4 αを介して情報保管装置として の WWWサーバ 3 αに転送する。
なお、 共通鍵の登録時には転送処理を行わない。 デジタル署名確認部 1 7ひは、 WWWサーバ 3 ひ に保管されている特定 グループに属する公開鍵のメンバーリス ト G L αをネッ 卜ワーク 4 αを介 して受けて、 チームマスタ一のデジタル署名を確認し、 確認が肯定的であ る場合、 新規にグループに加入するユーザの公開鍵を追加するときは、 そ 19 の公開鍵 P Kを記憶部 1 3 αから公開鍵管理部 1 8 αに出力させ、 脱会す るメンバ一があるときには受け取ったメンパーリ ス 卜に記載されているメ ンバーから該当メンバ一を削除させ、 また、 共有鍵を登録するときには、 公開鍵 I Dリストに応じた公開鍵 Ρ Κ αを記憶部 1 3 αから暗号化鍵生成 部 1 4 αに出力させる。 公開鍵管理部 1 8 αは、 新規にグループに加入するユーザの公開鍵を追 加するときに、 記憶部 1 3 αから出力された指定公開鍵 Ρ Κ αを受けて、 新しいメ ンバーリ ス 卜を作成し、 公開鍵番号 （Ν ο )、 メンバーの公開鍵 をリス 卜に設定し、 さらに新規のメンバ一リス 卜に対してグループ I Dを 付加してデジタル署名付加部 1 9 αに出力する。 また、 たとえば特定グル —プのメ ンバ一リ ス ト要求等が発生した場合、 この要求を WWWサーバ 3 αに対して行う。 デジタル署名付加部 1 9 ひは、 公開鍵管理部 1 8 αによる新規のメ —リス トに対してチームマスターのデジタル署名を付加し、 ネッ トワーク 4 αを介して情報保管装置としての WWWサーバ 3 αに転送し、 登録させ る。 復号化部 2 0 αは、 特定グループで共通鍵を共有している場合には、 W WWサーバ 3 aに登録されている共通鍵リス 卜 C K L αの中から所望の共 通鍵番号 （Ν ο )、 暗号化鍵を取得し、 公開鍵暗号方式 （たとえば、 R S Α ) を用いてユーザの秘密鍵 ρ V k ひで暗号化鍵を復号して共通鍵を取得 し、 暗号化部 1 1 αに出力する。
また、 WWWサーバ 3 ひ に登録されているデ一タを復号する場合には、 データ I D , 公開鍵番号 （N o ) を WWWサーバ 3 ひ に転送して、 暗号化 20 鍵およびデータを取得し、 公開鍵暗号方式を用いて、 共通鍵を復号し、 共 通鍵暗号方式を用いてデータを復号する。
この復号部 2 O c は、 図 3に示すように、 暗号化鍵復号化部 2 1 ひ 、 情 報復号化部 2 2 αにより構成される。 なお、複号化部 2 0 αは、たとえば WWWサーバ 3 aに複数の暗号化鍵、 付加情報、 および暗号化データに加えて保管されている共有鍵暗号方式、 公開鍵暗号方式のアルゴリズムを識別するためアルゴリ ズム識別情報 d e s r s a (たとえば、 D E Sと R S Aで暗号化した、 など） や、 暗号化ァ ルゴリ ズムの実行に必要な上記以外の情報 i n f o (たとえば、 D E Sに 利用した初期化乱数など） も、 取得する。
そして、 たとえば、 アルゴリ ズム識別情報 d e s r s a、 情報 i n f o に基づいて、 複号化に利用できるように、 アルゴリズムを初期化する処理 等も行う。 rサーバ 3 αは、 図 4に示すように、 データベースマネージメント システム （D BMS ) 3 1 αおよび権限確認機能を有する権限確認部 3 2 αを有しており、 メンバ一リス ト G L a、 共通鍵リス ト C K L α、 グルー プの共通鍵リ ス ト G C K L α、 暗号化データリ ス ト E D L α、 およびデ一 タ共通鍵リス ト D C K L αを所定の記憶部に記録し、 保管する。
D BMS 3 1 aは、図 5 に示すように、 メ ンバ一リ ス ト管理部 3 1 1 α、 共通鍵管理部 3 1 2 ひ 、 および暗号化データ管理部 3 1 3 ひ の 3つの情報 管理保管機能を有している。 これらの機能は、 権限確認機能を利用して、 各変更や登録、 データ保管要求が権限を満たしているか否かを確認する。 21 メンバ一リス ト管理部 3 1 1 αは、 クライアン ト側からのメンバーリス ト変更要求時に、 メンバ一リス ト G L αにアクセスして、 メンバ一変更要 求に対して応答し、 返信されてきたチームマスタ一の要求に従ってメンバ —リ ス ト G L αを変更する。 また、 メンバーリス 卜管理部 3 1 1 ひは、 グ ループ全体を追加 ·削除する機能を有している。 共通鍵管理部 3 1 2 αは、 共通鍵登録時に、 共通鍵リス ト C K L aとグ ループの共通鍵リス ト G C K L aにアクセスし、 共通鍵の登録を行う。 共通鍵管理部 3 1 2 ひは、 クライアン卜からの共通鍵要求に対して、 そ の時点 ·特定グループでの情報共有に最適な共通鍵 （特定グループで複数 の共通鍵 （随時更新されていく） を有している場合には、 最新の共通鍵） を選択して、 クライアン トに転送する。 また、 たとえば登録対象の共通鍵 に関する暗号化鍵、 グループ I D情報を受信したならば、 各リ ス トに振り 分けて保管する。 そのとき、 共通鍵 I Dを生成する。 また、 特定グループへのメンバ一の新規登録時に、 新規メンバ一が、 登 録時点よりも前にグルーァで共有されていた情報を読めるように各リ ス ト を変更する場合には、 メンバーリス ト管理部 3 1 1 αおよび共通鍵管理部 3 1 2 αは協働して以下に示すような処理を行う。 この場合、 メンバ一リス ト管理部 3 1 1 aは、権限を確認するとともに、 グループ I Dを参照して特定グループに属するメンバーの公開鍵番号 （N o)、 公開鍵をメンバ一リス ト G Lひより取得する。
共通鍵管理部 3 1 2 ひは、 グループの共通鍵リス ト G C K L aよりグル —プ I Dを参照して、 特定グループで利用されている共通鍵番号 （N o ) を全て検索する。 そして、 共通鍵リス ト C K L αより、 各共通鍵番号 （Ν 22 . o ) とチームマスタ一の公開鍵番号 （N o) がー致する全ての暗号化鍵を 取得し、 クライアントに転送する。
そして、メンバ一リス ト管理部 3 1 1 ひおよび共通鍵管理部 3 1 2 αは、 クライアント側で変更、 暗号化等の処理の結果、 返信されてきた暗号化鍵 とメンバーリス ト、 公開鍵番号 （No) と共通鍵 I Dを受けて、 メンバ一 リス ト G L α、 共通鍵リス ト C K L α、 グループの共通鍵リス ト G C K L を変更する。
これにより、 新規追加されたメンバ一は、 共通鍵リス トに自分の公開鍵 が含まれているので、 過去の共有情報を、 取得することができる。 また、特定グループからのメンバ一の削除時に、削除されたメンバ一が、 削除以後、 グループで共有されていた情報を読めないようにするために各 リストを変更する場合、 メンバ一リス ト管理部 3 1 1 αおよび共通鍵管理 部 3 1 2 αは、 協働して以下に示すような処理を行う。 この場合、 メンバーリ ス ト管理部 3 1 1 αは、 メンバ一リス 卜の更新を 行う。 最後の返信部分では、 新しいメンバ一リス トと更新前のメンバーリ ス トとを比較し、 削除したメンバーの公開鍵番号 （N o) を割り出し、 グ ループ I Dと削除したメンバーの公開鍵番号 （N o) を共通鍵管理部 3 1 2 αにわたす。
共通鍵管理部 3 1 2 αは、 グループの共通鍵リ ス ト GCKLひより、 グ ループ I Dを参照して、特定グループで利用されていた共通鍵番号（No) を全て検索し、 共通鍵リ ス ト C K L αより、 各共通鍵番号 （N o) と削除 したメンバ一の公開鍵番号（N o ) がー致する全ての暗号化鍵を削除する。 なお、 DBMS 3 1 αでは、 メンバ一の追加と削除が同時に行われた場 23 . 合には、 上述した手法が組み合わされて実行される。 暗号化データ保管部 3 1 3 αは、 共通鍵管理部 3 1 2 αと協働して、 グ ループの共通鍵リ ス ト G C K L α、 共通鍵リス ト C K L a、 データ共通鍵 リス ト D C K L a、 暗号化データリス ト E D L aをアクセスし、 クライア ン卜の要求に従ってメンパーリス 卜の送信と暗号化データの受付を行い、 データ I Dを生成する。 また、 複号化要求を受け取った場合には、 データ I Dと公開鍵番号 （N o ) を参照し、 3つのリス トを参照して暗号化デー タと暗号化鍵を返信する。 次に、 上記構成による動作を説明する。
なお、 ここでは、 グループで共通鍵を共有する場合であって、 グループ への公開鍵 I Dの登録例、 共通鍵の登録例、データの暗号化および登録例、 共通したいユーザを別途指定する場合の暗号化例、 並びにデータの復号化 例について、 図 6〜図 1 0に関連付けて順を追って説明する。 まず、 グループで共通鍵を共有する場合であって、 グループへの公開鍵 I Dの登録例について図 6に関連付けて説明する。
特定グループに属するメンバ一だけで情報を共有したい場合に、 まず、 グループに属するメンバーの公開鍵 I Dの登録が行われる。
この場合、 アクセス等の権限の確認が行われ、 クライアント側 （端末側） から特定グループのメンバーリス ト要求が WWWサーバ 3 aに対して、 た とえば公開鍵管理部 1 8 aから行われる （S 6 1 a )。 メンバ一リスト要求に対して、 WWWサーバ 3 aから特定グループに属 する公開鍵 I D リ ス 卜がネッ トヮ一ク 4 ひを介してクライアン 卜側暗号化 24 . 復号化装置 1 0 ひ に転送される （S 6 2 c c
暗号化複号化装置 1 0 ひ では、 デジタル署名確認部 1 7 ひ にこの公開鍵 リストであるメンバーリス 卜が入力され、 ここでチームマスターのデジタ ル署名の確認が行われる （S 6 3 a )。
確認が肯定的である場合、 新規にグループに加入するユーザの公開鍵を 追加するときは、 その公開鍵 P Kが記憶部 1 3 aから公開鍵管理部 1 8 a に出力され、 脱会するメンバーがあるときには受け取ったメンバ一リス ト に記載されているメンバーから該当メンバーの公開鍵が削除される （S 6 4 a )。 公開鍵管理部 1 8 aでは、 記憶部 1 3 ひから出力された指定公開鍵 P K を受けて、 新しいメンバ一リストが作成され （S 6 5 ひ）、 公開鍵番号 （N o )、 メ ンバーの公開鍵、 およびグループ I Dがリ ス トに設定されて、 デ ジタル署名付加部 1 9 aに出力される。 デジタル署名付加部 1 9 ひ において、 公開鍵管理部 1 8 aによる新規の メンバ一リス 卜に対してチームマスタ一のデジタル署名が付加される （S 6 ο ひ )。
そして、 たとえばデジタル署名付加部 1 9 aからメ ンバーリス ト更新要 求が WWWサ一バ 3 aに対して行われ、 WWWサーバ 3 aにおいてメンバ 一リス ト管理部 3 1 1 ひにより りメンバ一リ ス 卜 G L aの更新が行われる ( S 6 7 a ) π なお、 ステップ S 6 3 aにおいて、 デジタル署名確認が否定的である場 合には、 当該チームマスターはメ ンバーリス ト等の更新、 削除等を行う権 限のないものとして、 ステップ S 6 4 a以降の処理は行われない 25 -
次に、 グループで共通鍵を共有する場合であって、 共通鍵の登録例につ いて図 7に関連付けて説明する。
特定グループに属するメンバ一だけで情報を共有したい場合に、 そのメ ンバーで利用する共通鍵の登録が行われる。
この場合、 アクセス等の権限の確認が行われ、 クライアント側 （端末側） から特定グループのメンバ一リス 卜要求が WWWサーバ 3 αに対して、 た とえば暗号化鍵生成部 1 4 αから行われる （S 7 1 α )。 メンバ一リス 卜要求に対して、 WWWサーバ 3 αから特定グループに属 する公開鍵 I Dリス 卜がネッ トワーク 4 αを介してクライアン ト側暗号化 復号化装置 1 0 αに転送される （S 7 2 ct )。
暗号化復号化装置 1 0 ひでは、 デジタル署名確認部 1 7 αにこの公開鍵 リス トであるメンバ一リス トが入力され、 ここでチームマスタ一のデジタ ル署名の確認が行われる （S 7 3 a )。 確認が肯定的である場合、 公開鍵 I D リ ス 卜に応じた公開鍵 P Kが記憶 部 1 3 ひから暗号化鍵生成部 1 4 ひに出力される。
暗号化鍵生成部 1 4 αでは、 共通鍵生成部 1 2 αで生成された共通鍵 S k e y 1 αが、 与えられた公開鍵を用いてたとえば公開鍵暗号方式に基づ いて暗号化され、 図 7に示すように、 公開鍵番号、 メンバ一公開鍵を含む 共通鍵リス ト用データを付加して 1または複数の暗号化鍵 Ε Κ αが生成さ れ、 転送部 1 6 αに出力される （ S 7 4 ひ）。
そして、 転送部 1 6 ひにより公開鍵番号、 メンバ一公開鍵を含む共通鍵 リス ト用データが付加された暗号化鍵を含む共通鍵リ ス トデータがネッ ト ワーク 4 αを介して WWWサーバ 3 αに転送され、 共通鍵管理部 3 1 2 α 26 により図 7に示すように所定の場所に保管される （S 7 5 a)c
なお、 転送場 1 6 ひから転送される情報には、 付加情報生成部 1 5 ひで 生成された付加情報が含まれる場合もある。 なお、 ステップ S 7 3 ひにおいて、 デジタル署名確認が否定的である場 合には、当該チームマスタ一は共通鍵の登録を行う権限のないものとして、 ステップ S 7 4 α以降の処理は行われない。 次に、 グループで共通鍵を共有する場合であって、 データを暗号化する 場合について図 8に関連付けて説明する。
この場合、 アクセス等の権限の確認が行われ、 クライアント側 （端末側） から特定グループのメンバーリス ト要求、 具体的にはグループ I D、 ユー ザ公開鍵 I D (たとえば番号 「 I C ： F F」） の要求が WWWサーバ 3 α に対して、 たとえば暗号化部 1 1 αから行われる （S 8 1 ひ）。 メンバ一リス ト要求に対して、 WWWサーバ 3 から特定グループに属 する共通鍵 （たとえば 「 1 2 2」）、 暗号化鍵 （「 ζ X c ν」） がネッ トヮ一 ク 4 αを介してクライアント側暗号化復号化装置 1 0 αに転送される （S 8 2 α；)。 暗号化復号化装置 1 0 αでは、複号化部 2 0 αにおいて、共通鍵番号（ 1 2 2)、 暗号化鍵 （ z x c v ) が取得され、 公開鍵暗号方式を用いてュ一 ザの秘密鍵 ρ V k αで暗号化鍵が復号されて共通鍵 S k e y 2 αが取得さ れ、 暗号化部 1 1 αに出力されれる （S 8 3 a， S 8 4 a)。 暗号化部 1 1 αでは、 入力情報 Μα (「こんにちは」） が入力され、 この 27 . 入力情報 Mひが共有鍵暗号方式 （たとえば、 D E S ) に基づいて共通鍵 S k e y 2 αを用いて暗号化され、 共通鍵番号 （ 1 2 2 ) が付加された暗号 化データ Μ' α (たとえば 「； ijjjjjjjjjjjjjJ) が生成されて転送部 1 6 ひ に出 力される （ S 8 5 α )。
そして、 転送部 1 6 αにより共通鍵番号 （ 1 2 2 ) が付加された暗号化 データ M' a (たとえば rjjjjjjjjjjjjjjj) がネッ トワーク 4 αを介して WW Wサーバ 3 αに転送され、 暗号化データ管理部 3 1 3 αにより図 8に示す ように所定の場所に保管される （S 8 6 a)。 次に、 共有したいユーザを別途指定する場合であって、 データを暗号化 する場合について図 9に関連付けて説明する。
この場合、 入力情報 (「こんにちは」） が暗号化装置 1 0 αの暗号化 部 1 1 αに入力される。 このとき、 共通鍵生成部 1 2 ひ で、 共通鍵 S k e y 1 aが生成され （S 9 1 α)、 この共通鍵 S k e y 1 αが暗号化部 1 2 aおよび暗号化鍵生成部 1 4 ひ に供給される （S 9 2 a , S 9 3 a )0 暗号化部 1 1 aでは、 入力情報 M aが共有鍵喑号方式 D E Sに基づいて 共通鍵 S k e y 1 aを用いて暗号化され、共通鍵番号（たとえば「 1 2 4」） が付加された暗号化データ M' a (たとえば 「： jjjjjjjjjjjjjjj) が生成されて 転送部 1 6 aに出力される。 また、 暗号化鍵生成部 1 4 ひ によって、 ユーザ A、 B、 Cの公開鍵暗号 方式 （たとえば、 R S A) に基づいた公開鍵 P K aが記憶部 1 3 aから読 み出される。
暗号化鍵生成部 1 4 において、 これらそれぞれの公開鍵を利用して、 公開鍵喑号方式に基づいて共通鍵 S k e y 1 aが暗号化され、 たとえば喑 28 . 号化鍵 （o l k j ， 〇 i w i， X k n m) が得られ、 公開鍵番号 （「1 1 :
AA」、 「 1 C : F F」、 「E 5 : 4 B」） を含むデータが転送部 1 6 ひ に出 力される （ S 9 4 ひ ）。
そして、 転送部 1 6 αにより共通鍵番号 （たとえば 「 1 2 4」） が付加 された暗号化データ Μ' α (たとえば 「； jjjjjjjjjjjjjj」）、 並びに暗号化鍵 （o 1 k j , O i w i , X k n m)、 公開鍵番号 （「 1 1 : AA」、 「 1 C : F F」、 「E 5 ： 4 B」） を含むデータがネッ トワーク 4 αを介して WWWサーバ
3 aに転送され、 図 9に示すように所定の場所に保管される （S 9 5 α)0 次に、 WWWサーバ 3 αに保管されているデータを取得する場合を、 図 1 0に関連付けて説明する。
この場合、 たとえば復号化部 2 0 αからデータ I D (たとえば 「4 4 4 4」）、 公開鍵 I Dが、 WWWサ一バ 3 aに対して送信される （S 1 0 1 α)。
WWWサーバ 3 αでは、 受けたデータ I Dおよびこれに基づく共通鍵番 号 （たとえば 「1 2 2 J) により、 暗号化データ （たとえば 「； jjjjjjjjjjjjjjj) およびこれに対応した暗号化鍵 （ z X c V ) が暗号化データ管理部 3 1 3 αにより所定の保管場所から読み出され、 ネッ トワーク 4 ctを介してクラ イアン ト側へ転送される （S 1 0 2 ひ）。 復号化部 2 0 αでは、 公開鍵暗号方式を用いて、 公開鍵 I Dに対応した 秘密鍵を用いて共通鍵が S k e y 2 αとして復号される （S 1 0 3 ひ ）。 そして、 この共通鍵 S k e y 2 αを用いて、 共通鍵暗号方式に基づきデ —タが 「こんにちは」 と して復号される （S 1 0 4 a )。 次に、 特定グループへのメンバ一の新規登録時に、 新規メンバ一が、 登 録時点よりも前にグループで共有されていた情報を読めるように各リス ト 29 . を変更する場合、 および特定グループからのメンバーの削除時に、 削除さ れたメンバ一が、 削除以後、 グループで共有されていた情報を読めないよ うにするために各リストを変更する場合の WWWサーバ 3 αにおける動作 を説明する。 まず、 特定グループへのメンバーの新規登録時に、 新規メンバ一が、 登 録時点よりも前にグループで共有されていた情報を読めるように各リス ト を変更する場合について説明する。
この場合、 WWWサーバ 3 aにおいては、 メンバ一リ ス ト管理部 3 1 1 aにより、 権限が確認されるとともに、 グループ I Dを参照して特定ダル —プ （たとえば、 Bチーム） に属するメンバ一の公開鍵番号 （N o)、 公 開鍵がメンバーリス ト G L aから取得される。
そして、 共通鍵管理部 3 1 2 aで、 グループの共通鍵リス ト GCK L a よりグループ I Dが参照され、 特定グループ （たとえば、 Bチーム） で利 用されている共通鍵番号 （たとえば、 5 2、 1 1 1、 1 2 3 ) が全て検索 される。
さらに、 共通鍵管理部 3 1 2 aにおいて、 共通鍵リス ト C K L aより、 各共通鍵番号 （たとえば、 5 2、 1 1 1、 1 2 3 ) とチームマスターの公 開鍵番号 （たとえば、 1 1 ： AA) がー致する全ての暗号化鍵 （たとえば、 qwer、 peha、 gobp) が取得され、 チームマスタ一のクライアン トに転送 される。 チームマスタ一の暗号化復号化装置 1 0 ひでは、 メンバーリス トと全て の暗号化鍵を復号化した共通鍵 （たとえば、 S k e y l O O ひ 、 S k e y 1 0 5 ひ 、 S k e y 8 0 α ) が得られる。 図 6を参照して説明したように、 メンバーリス トの変更が行れた後、 それらの共通鍵が、 新規登録されたメ 30 ンバ一の公開鍵を利用して喑号化される （たとえば、 xhen、 mxco、 henc)。 そして、 これらの暗号化鍵とメンバ一リス ト、 公開鍵番号 （たとえば、 L 2 ： CA) と共通鍵 I D (たとえば、 5 2、 1 1 1、 1 23) が WWW サーバ 3 αに送信される。 メンバ一リス ト管理部 3 1 1 αおよび共通鍵管理部 3 1 2 αでは、 クラ イアント側で変更、 暗号化等の処理の結果、 返信されてきた暗号化鍵とメ ンバ一リス ト、 公開鍵番号 （N o) と共通鍵 I Dを受けて、 メンバ一リス ト G Lひ 、 共通鍵リス ト C K L α、 グループの共通鍵リス ト GCKL a力 変更される。
これにより、 新規追加されたメンバ一は、 共通鍵リス トに自分の公開鍵 が含まれているので、過去の共有情報を取得することができるようになる。 次に、特定グループからのメンバーの削除時に、削除されたメンバ一が、 削除以後、 グループで共有されていた情報を読めないようにするために各 リス トを変更する場合について説明する。 この場合、 WWWサーバ 3 αのメ ンバ一リス ト管理部 3 1 1 ひでは、 メ ンバ一リス トの更新が行われる。 このとき、 最後の返信部分では、 新しい メンバ一リス トと更新前のメンバ一リス トとが比較され、 削除したメンバ —の公開鍵番号 （N o) が割り出される。 そして、 グループ I Dと削除し たメンバーの公開鍵番号 （N o) が共通鍵管理部 3 1 2 αにわたされる。 共通鍵管理部 3 1 2 αでは、 グループの共通鍵リス ト G CKL aより、 グループ I Dを参照して、 特定グループ （たとえば、 Bチーム） で利用さ れていた共通鍵番号 （たとえば、 3 8、 444、 1 3 3) が全て検索され る。 31 · 次いで、 共通鍵管理部 3 1 2 ひでは、 共通鍵リ ス ト C K L aより、 各共 通鍵番号 （たとえば、 3 8、 4 4 4、 1 3 3 ) と削除したメンバーの公開 鍵番号 （たとえば、 L L ： B B ) がー致する全ての暗号化鍵が削除される。 なお、 WWWサーバ 3 ひ 、 具体的には、 D B M S 3 1 ひでは、 メンバー の追加と削除が同時に行われた場合には、 上述した手法が組み合わされて 実行される。 以上説明したように、 本実施形態によれば、 少なく とも複数のメ でアクセス可能で、 少なく ともチームマスターのデジタル署名、 メンバー 公開鍵情報を含むメンバ一リス ト、 暗号化鍵情報を含む共通鍵リス ト、 お よび暗号化データが保管される WWWサーバ 3 ひ と、 情報を見てもよい少 なく とも一のメンバーの公開鍵を記憶する記憶部 1 3 α と、 情報を暗号化 するための共通鍵を用いて上記共通鍵暗号化方式に基づいて入力情報を喑 号化して暗号化データを生成する暗号化部 1 1 αと、 暗号化に用いた共通 鍵を、 記憶部に記憶され指定された公開鍵で暗号化し、 暗号化鍵を生成す る暗号化鍵生成部 1 4 αと、 複数の暗号化鍵および暗号化データを WWW サーバ 3 αに転送し保管させる転送部 1 6 αと、 WWWサーバ 3 αからメ ンバ一リス トを取得して、 当該メンパーリス トのチームマスターのデジタ ル署名が指定されたデジタル署名と一致するか否かを判断し、 一致する場 合にのみメンバ一の公開鍵の追加または脱会するメンバーの公開鍵の削除 を上記記憶部に対して行い、 追加登録または削除の場合、 少なく ともチ一 ムマスタ一のデジタル署名、 メンバ一公開鍵情報を含む新メンバーリス ト を作成！：て上記情報保管装置に転送し保管させるリ ス ト管理部 1 7 α , 1 8 , 1 9 αと、 WWWサーバ 3 αから所望の暗号化鍵情報および暗号化 データを取得して、 この暗号化鍵情報から共通鍵を復号し、 復号した共通 32 . 鍵で取得した暗号化データを復号する複号化部 2 0 αとを有する暗号化復 号化装置 1 0 ひとをインターネッ ト 4 ひで接続したので、 グループで共有 鍵を共有することができ、 暗号化データを保管するデータべ一スゃ、 サ一 バ、 ファイルシステムの管理者に情報の内容を見られてしまう可能性もな い。
したがって、 権限のない、 サーバ等の情報保管装置の管理者の視き見、 改竄を防ぐことができる。 また、 本実施形態では、 情報保管装置としての WWWサーバ 3 αに、 ク ライアン ト側からのメンバーリス ト変更要求時に、 メンバーリ ス ト G L ひ にアクセスして、 メンバー変更要求に対して応答し、 返信されてきたチー ムマスタ一の要求に従ってメンバーリス 卜 G L α を変更可能なメンバ一リ スト管理部 3 1 1 αと、 クライアントからの共通鍵要求に対して、 その時 点 ·特定グループでの情報共有に最適な共通鍵を選択して、 クライアント に転送する共通鍵管理部 3 1 2 αと、グループの共通鍵リス ト G C K L a、 共通鍵リス ト C K L ひ、 データ共通鍵リス 卜 D C K L ひ、 暗号化データリ ス ト E D L aをアクセス し、 クライアン 卜の要求に従ってメ ンバ一リ ス 卜 の送信と暗号化データの受付を行い、 データ I Dを生成し、 複号化要求を 受け取った場合には、 データ I Dと公開鍵番号 （N o ) を参照し、 3つの リス トを参照して暗号化データと暗号化鍵を返信する暗号化データ保管部 3 1 3 ひ とを設けたので、 暗号化データを保管するデータベースや、 サー ノく、 ファイルシステム等の情報保管装置を利用して共有されるユーザのデ —タが司見き見されたり、 改竄されるおそれもなく、 データの管理を確実に 行うことができる c なお、 暗号化複合化装置 1 0 αにおけるメ ンバーリス トの作成、 登録、 33 . 削除、 共通鍵の作成、 登録、 登録された共通鍵を用いたデータの暗号化、 サーバ 3 aに登録されたデータの復号処理工程を実行するためのプロダラ ム、 あるいはサーバ 3におけるリス トの変更、 登録、 保管等のプログラム は、 第 1および第 2の端末装置 （コンピュータ） 1 α， 2 αで読み出し可 能な記録媒体、 たとえば暗号化装置 1 0 αやサーバ等に設けられたフロッ ピ一ディスク、 ハードディスク、 光ディスク、 半導体記憶装置等に記録さ れ、 端末装置で読み出されて実行される。
また、 他の例としては、 たとえばインタ一ネッ トの専用線や電話回線等 の通信線路のように、 通信プログラムに伝送する際にこの通信プログラム を一定時間保持するデータ伝送路等を挙げることができる。 また、 本実施形態の情報保管装置および暗号化複合化装置 1 0 αに、 送 信側から受信側へ情報またはデータが送信された場合、 前記送信側から情 報またはデータの送信が行われたことを受信側に対し通知する送信通知と、 受信側が確実に前記情報を受信したことを送信側に対し通知する受信通知 とを行う送受信通知部 （図示せず） をさらに備える構成としてもよい。 この構成とすることで、 受信者は送受信通知部を利用して受信時 （改竄 確認および復号後） に、 送信者または情報が中継された情報通信装置また は情報保管装置に対して、 確かに受信した旨を確認するための受信通知を 送信することができる。 なお、 これらの通知に含まれる情報として、 送信 者から転送された情報の内容 （もしくは、 その一部）、 概要、 発信者を特 定する情報、 受信者を特定する情報、 情報取得 ·保管場所 （たとえば U R Lア ドレス、 ディレク トリ等）、 情報取得日時などがある c 具体的には、 情報保管装置では、 図 5の暗号化データ管理部 （3 1 3 α ) 34 . に、 送受信通知部の機能をもたせる。 また、 暗号化複合化装置では、 暗号 化に利用したもしくは、 復号時に取得できた上述の通知に含まれる情報を 利用して送信通知または受信通知を作成し、通信する。通信手段としては、 端末に接続されたメ一ルプロ トコルゃ、 ブラウザなどが備える H T T Pプ 口 トコルなどの外部の通信機能を代用して利用することができる。 上記構成とするのは、 機密性の高い情報 （たとえば、 契約書等） を通信 する場合に、 通信の安全性を高めるために、 確実に通信を行われたことを 送受信者が確認することが望ましいからである。 送信者は、 送受信通知部 を利用して送信時 （暗号化時） に、 受信者または情報が中継された情報中 継装置または情報保管装置に対して、 確かに送信した旨を周知するための 送信通知を送信することができる。 たとえば、 H T T P通信で情報の転送 を行う場合には、 S M T Pなど別のプロ トコルを利用した通知を転送する ことによって、 通信の存在を送受信両者で確認することにより、 より安全 性を高めることができる。 以上説明したように、 第 1の実施形態の発明によれば、 グループで共有 鍵を共有することができ、 暗号化データを保管するデータベースや、 サ一 ノく、 ファイルシステムの管理者に情報の内容を見られてしまう可能性もな レ、。
[第 2の実施形態]
第 2の実施形態の発明は、 例えば、 ネッ トワーク伝送における情報改竄 の検知に用いられる情報改竄検知装置および改竄検知プログラムを記録し たコンピュータ読み取り可能な記録媒体に関する。 35 第 2の実施形態の発明に関し、 従来以下説明する技術が知られている。 従来、 情報の改竄を検知する技術 （以下、 情報改竄検知技術と称する） としては、デジタル署名技術が情報改竄検知装置により実用化されている。 一般的なデジタル署名技術の例としては、 Digital Signature Algorithm や公開鍵暗号方式 （例えば R S A方式） とハッシュ関数 （例えば、 M D 2 ) と組み合わせるものがある。 図 1 7は、 上述した従来の情報改竄検知装置の動作原理を説明する図で ある。 図 1 7に示す情報改竄検知装置は、 送信者側に設置された送信端末
1 ]3と、 該送信端末 1 β と図示しないネッ トワーク （ィンターネッ ト等） を介して接続され、 受信者側に設置された受信端末 6 βとから概略構成さ れている。 この情報改竄検知装置において、 暗号化、 複号化には、 公開鍵 および秘密鍵が用いられる。 この公開鍵と秘密鍵とは、 秘密鍵から公開鍵 が計算により求めることができる一方、 逆に公開鍵から秘密鍵が計算によ り求めることができないという関係とされている。 上記構成において、 ステップ S A 1 では、 送信端末 1 ]3は、 受信端末 6 へ送信すべき平文 2 を暗号化する。 具体的には、 送信端末 l j3は、 受信者 （受信端末 6 ]3 ) の公開鍵を利用して平文 2 βから暗号文 3 を作 成する。 次いで、 ステップ S A 2 では
、送信端末 1 ]3は、ハッシュ関数を用いて平文 2 3を圧縮して、 M D j3 (メ ッセージダイジェス ト） 4 a |3を作成する。 ここで、 ハッシュ関数とは、 同じ出力値になる任意の 2つの異なる入力 を発見することが計算量的に実行不可能な関数をいい、 デジタル署名等の メ力二ズムの一部と して利用する目的で、 長いメッセージから比較的短い 36 . 一定値長の圧縮デ一タをハッシュ符号として作成するための一方向関数を いう。
次に、 ステップ S A 3 |3では、 送信端末 1 βは、 送信者 （送信端末 1 /3 ) の秘密鍵を利用して MD ]3 4 a /3から認証子 5 3を作成する。 この認証子 5 は、 暗号文 3 ]3のもとになる平文 2 /3に対してされたデジタル署名で ある。
ここでは、 デジタル署名は、 メッセージダイジェス トの作成という第 1 プロセス、 該メッセージダイジュストに対する秘密鍵による暗号化という 第 2プロセスを経てなされるものである。
また、 デジタル署名は、 上記プロセスの他にメ ッセージダイジェス ト化 されていない情報、 またはメッセ一ジダイジエス トと該情報とを組み合わ せたものに対する秘密鍵による暗号化というプロセスを経てなされる場合 も含む。 そして、 送信端末 1 は、 上記暗号文 3 /3および認証子 5 j3をネッ トヮ —クを介して、 受信端末 6 /3へ送信する。 これにより、 受信端末 6 13は、 暗号文 3 /3および認証子 5 を受信した後、 まず、 ステップ S A 4 j3で受 信者 （受信端末 6 3 ) の秘密鍵を利用して暗号文 3 ;3を復号化して、 平文 20を作成する。 次いで、 ステップ S A 50では、 受信端末 6 は、 ノヽッ シュ関数を用いて復号化された平文 2 βを圧縮することにより、 MD β 4 b βを作成する。 また、 ステップ S A 6 j3では、 受信端末 6 3は、 受信された認証子 5 を送信者 （送信端末 1 β ) の公開鍵を利用することにより複号化して、 Μ D β 4 c βを作成する。
そして、 ステップ S A 7 ;3では、 受信端末 6 βは、 MD j3 4 b ι3と MD 37 .
|3 4 c βとを比較することにより、 転送情報 （暗号文 3 および認証子 5 β ) に改竄が行われたか否かの改竄検証を行う。 ここで、 M D |3 4 b と Μ Ό β 4 c βとが一致している場合には、 転送情報に対して改竄が行われ ていないことを意味する一方、 両者が不一致である場合には、 転送情報に 対して改竄が行われていることを意味する。 ところで、 従来の情報改竄検知装置においては、 図 1 7に示すように、 受信した暗号文 3 βを複号化する権利を有する受信端末 6 βでは、転送（送 if ) 途中で転送情報に対して改竄が行われたか否かを、 M D |3 4 b ]3と M D ]3 4 c /3との比較結果から検知することができる。 しかしながら、 従来の情報改竄検知装置においては、 図 1 8に示すよう に受信した暗号文 3 βを複号化する権利を有しない、 言い換えれば、 受信 者の秘密鍵を有しない受信端末 6 βでは、 平文 2 ι3ひいては M D β 4 b β を作成することができないため、 転送情報に対する改竄検証を行うことが できないという欠点があった。 したがって、 従来の情報改竄検知装置においては、 図 1 8に示す受信端 末 6 ]3が更に図示しない別の端末へ転送情報を転送した場合、 該端末は、 たとえ、 暗号文 3 /3を複号化する権利を有していても、 改竄がいつどこで 行われたかを検知することができない。 さらに、 従来の情報改竄検知装置 においては、 最初に転送情報を転送する送信端末 1 /3がもとの平文 2 ]3よ り作成された認証子 5 3 (デジタル署名） でないデジタル署名を転送した 場合であっても、 上記端末が改竄を検知することができない。 つまり、 従 来の情報改竄検知装置においては、 重要な転送情報に対して改竄が行われ た場合、 改竄が行われた端末 （場所）、 時間の特定が重要になるが、 これ 38 . らの検知 ·特定を行うことができないのである。 本発明はこのような背景の下になされたもので、 受信した情報を復号化 する権利を有しない端末であっても、 情報の改竄を検知することができる 情報改竄検知装置および改竄検知プログラムを記録したコンピュータ読み 取り可能な記録媒体を提供することを目的とする。 以下、 図面を参照して第 2の実施形態について説明する。 図 1 1は本発 明の一実施形態 （第 2の実施形態） による情報改竄検知装置の動作原理を 説明する図である。 この図に示す情報改竄検知装置は、 送信者側に設置さ れた端末 1 0 0 と、 該端末 1 0 0 ]3にインタ一ネッ ト等のネッ トワーク Ν βを介して接続された端末 2 0 0 βとから概略構成されている。 上記構成において、 ステップ S B 1 )3では、 端末 1 0 0 (3は、 ハッシュ 関数を用いて転送情報 1 1 ]3を圧縮して、 転送情報 MD /3 (メッセージダ イジヱス ト） 1 2 a 3を作成する。 この転送情報 MD /3 1 2 a 3は、 後述 するように送信者の転送内容と受信者の受信内容とが相違していないか否 かの検証に用いられる。 次いで、 端末 1 0 0 |3は、 上記転送情報 1 1 βを ネッ トワーク Ν を介して端末 2 0 0 |3へ送信 （転送） する。 これにより、 端末 2 0 0 /3は、 転送情報 1 1 βを受信した後、 ステップ S B 2 /3で、 ハッシュ関数を用いて転送情報 1 1 ]3を圧縮して、 転送情報 MD j3 1 2 b /3を作成する。 ここで、 転送情報 1 1 /3に対する改竄が行わ れていない場合、 上記転送情報 MD β 1 2 b βと転送情報 MD β I 2 a β とは、 同一である。 一方、 改竄が行われた場合、 転送情報 MD ]3 1 2 b β と転送情報 MD ]3 1 2 a |3 とは、 異なる。 39 .
そして、 ステップ S B 3 i3では、 端末 2 0 0 j3は、 受信者 （端末 2 0 0 β ) の秘密鍵を利用して転送情報 MD 1 2 b )3を暗号化して、 受信内容 確認情報 1 3 ]3を生成する。 この受信内容確認情報 1 3 ]3は、 .転送情報 M Ό β 1 2 b βに対して受信者 （端末 2 0 0 /3 ) によるデジタル署名が行わ れたものであり、 受信者 （端末 2 0 0 ]3 ) が転送内容 （転送情報 1 1 β ) を受信したことを証明する情報である。
ここでは、 デジタル署名は、 メッセージダイジェス ト化、 暗号化という 2つのプロセスを経てなされたものである。
また、 デジタル署名は、 上記プロセスの他にメッセージダイジェス ト化 されていない情報、 またはメッセージダイジエス トと該情報とを組み合わ せたものに対する秘密鍵による暗号化というプロセスを経てなされる場合 も含む。
要はデジタル署名は、 圧縮されている、 いないに関わらずある情報に対 して秘密鍵により暗号化されたものである。
次いで、 端末 2 0 0 )3は、 上記受信内容確認情報 1 3 iSをネッ トワーク N βを介して端末 1 0 0 )3へ送信する。 これにより、 端末 1 0 0 )3は、 上記受信内容確認情報 1 3 ]3を受信した 後、 ステップ S B 4 /3で、 受信者 （端末 2 0 0 ]3 ) の公開鍵により受信内 容確認情報 1 3 を複号化して、 転送情報 MD β 1 2 c βを作成する。 次 に、 ステップ S Β 5 (3では、 端末 1 0 0 )3は、 転送情報 MD ]3 1 2 c ]3と 転送情報 MD β 1 2 a βとを比較することにより、 改竄が行われたか否か を検証する。 具体的には、 端末 1 0 0 /3は、 転送情報 MD ]3 1 2 a /3と転 送情報 MD /3 1 2 c |3とが同一である場合、検証結果を未改竄とする一方、 転送情報 MD β 1 2 a βと転送情報 MD 0 1 2 c /3とが異なる場合、 検証 40 結果を改竄とする。 次に、 ステップ S B 6 j3では、 端末 1 0 0 ]3は、 送信者 （端末 1 0 0 |3 ) の秘密鍵を利用して受信内容確認情報 1 3 ]3を暗号化して、 送信内容確認 情報 1 4 βを作成する。 この送信内容確認情報 1 4 J3は、 受信内容確認情 報 1 3 に対して送信者 （端末 1 0 0 ]3 ) によるデジタル署名が行われた ものであり、 送信者 （端末 1 0 0 ]3 ) 、 受信者 （端末 2 0 0 j3 ) の受信 した転送内容 （転送情報 1 1 ]3 ) を送信したことを証明するための情報で ある。 また、 送信内容確認情報 1 4 /3は、 受信者 （端末 2 0 0 ^) が転送 内容 （転送情報 1 1 i3 ) を保有してもよいことを証明するための情報であ る。 図 1 2は、 本発明の一実施形態による情報改竄検知装置の具体的な構成 を示すブロック図である。 この図において、 図 1 1の各部に対応する部分 には同一の符号を付ける。 図 1 2に示す端末 1 0 0 /3において、 1 0 1 /3 は、 転送情報 1 1 J3をネッ トワーク N |3を介して端末 2 0 0 へ送信する 情報送信部である。 1 0 2 ι3は、 端末 2 0 0 j3から送信される受信内容確 認情報 1 3 /3 (図 1 1参照） をネッ トワーク N 3を介して受信する情報受 信部である。
1 0 3 ]3は、 図 1 1に示すステップ S B l j3、 S B 4 0および S B 5 3 の処理を実行する受信内容確認情報確認部であり、 メ ッセージダイジュス ト作成部 1 0 3 a /3、 送信者 ·通信 ·受信者情報取得部 1 0 3 b および デジタル署名確認部 1 0 3 C J3 とを有している。 受信内容確認情報確認部 1 0 3 0において、 メッセ一ジダイジエス 卜作成部 1 0 3 a )3は、 図 1 1 ップ S B 1 βの処理を実行するものであり、 転送情報 1 1 βを 41 ハッシュ関数で圧縮して転送情報 MD ]3 1 2 a /3を作成する。 送信者 ·通 信 ·受信者情報取得部 1 0 3 b )3は、 転送情報 1 1 ]3、 受信内容確認情報 1 3 ;3から各送信者情報、 通信情報、 受信者情報を取得する。 ここで、 送信者情報は、 送信者 （端末 1 00 ） に関する情報であり、 「送信者名」、 「 I D」、 「公開鍵 I D」、 「メールア ドレス」、 信頼性が高い 第三者機関によって発行された 「電子証明書」 等の情報である。 また、 通 信情報は、端末 1 00 |3と端末 200 ^3との間の通信に関する情報であり、 「通信時間」、 「受信時間」、 「通信方式」、 「通信 I D」 等の情報である。 ま た、 受信者情報は、 受信者 （端末 2 00 ]3) に関する情報であり、 「受信 者名」、 「 I D」、 「公開鍵 I D」、 「メールア ドレス」、 信頼性が高い第三者 機関によって発行された 「電子証明書」 等の情報である。
図 1 2に示すデジタル署名確認部 1 03 c ]3は、 受信内容確認情報 1 3 β (図 1 1参照） のデジタル署名が受信者 （端末 200 ]3) によるもので あるかを確認する。
1 04 /3は、 図 1 1に示すステップ S Β 6 3等の処理を実行する送信內 容確認情報作成部であり、 メッセージダイジェス ト作成部 1 04 a )3、 送 信者 ·通信 ·受信者情報取得部 1 04 b ]3およびメッセージダイジェス ト 作成部 1 04 a ]3とを有している。 この送信内容確認情報作成部 1 04 |3 は、 受信内容確認情報 1 3 βに基づいて、 送信内容確認情報 1 4 βを作成 する。 この送信内容確認情報作成部 1 04 /3において、 メッセージダイジエス ト作成部 1 04 a は、 受信内容確認情報 1 3 /3からメ ッセージダイジェ ス トを作成する。 送信者 ·通信 ·受信者情報取得部 1 04 b /3は、 上述し 42 . た送信者 ·通信 ·受信者情報取得部 1 0 3 b ]3と同様にして、 受信内容確 認情報 1 3 /3から送信者情報、 通信情報および受信者情報を取得する。 デ ジタル署名付加部 1 0 4 c ι3は、 受信内容確認情報 1 3 |3を送信者 （端末 1 0 0 /3 ) の秘密鍵により暗号化することにより、 受信内容確認情報 1 3 βに対してデジタル署名を付加する。
1 0 5 /3は、 ネッ トワーク Ν ]3を介して送信内容確認情報 1 4 βを端末 2 0 0 へ送信する情報送信部である。 一方、 端末 2 0 0 ]3において、 2 0 1 i3は、 端末 1 0 0 |3からネッ トヮ ーク N /3を介して送信される転送情報 1 1 ]3を受信する情報受信部である。 2 0 2 は、 図 1 1に示すステップ S B 2 /3および S B 3 jSの処理を実行 する受信内容確認情報作成部であり、 メッセージダイジュス ト作成部 2 0 2 a |3、 送信者 ·通信 ·受信者情報取得部 2 0 2 b |3およびデジタル署名 付加部 2 0 2 c ;3とを有している。 この受信内容確認情報作成部 2 0 2 β は、 転送情報 1 1 )3に基づいて受信内容確認情報 1 3 ]3を作成する。 この受信内容確認情報作成部 2 0 2 において、 メッセージダイジヱス ト作成部 2 0 2 a ]3は、 転送情報 1 1 β をハッシュ関数で圧縮することに より、 転送情報 M D β 1 2 b β (図 1 1参照） を作成する。 送信者 ·通信 - 受信者情報取得部 2 0 2 b 13は、 上述した送信者 ·通信 ·受信者情報取得 部 1 0 3 b /3と同様にして、 転送情報 1 1 |3に関する送信者情報、 通信情 報および受信者情報を取得する。 デジタル署名付加部 2 0 2 c ]3は、 転送 情報 M D β 1 2 b β (図 1 1参照） を受信者 （端末 2 0 0 β ) の秘密鍵に より暗号化することにより、 転送情報 M D β 1 2 b βに対してデジタル署 名を付加する。 ここで、 このデジタル署名が付加された転送情報 M D /3 1 2 b は、 受信内容確認情報 1 3 βである。 43
また、 2 0 5 /3は、 端末 1 0 0 /3から送信された送信内容確認情報 1 4 J3の内容を転送情報 1 1 3に基づいて確認する送信内容確認情報確認部で あり、 メ ッセージダイジェス ト作成 ·取得部 2 0 5 a βと、送信者 .通信 · 受信者情報取得部 2 0 5 b 0と、 デジタル署名確認部 2 0 5 c ]3とを有し ている。 この送信内容確認情報確認部 2 0 5 βにおいて、 メッセージダイ ジエス ト作成■取得部 2 0 5 a |3は、 上述したメッセージダイジエストを 作成する機能と、 受信内容確認情報作成部 2 0 2 3のメ ッセージダイジェ ス ト作成部 2 0 2 a j3によりすでに作成された転送情報 M D β 1 2 b β (図 1 1参照） を取得する機能とを有する。 ここで、 上記転送情報 1 2 b βを取得した場合には、 メッセージダイジエス ト作成 ·取得部 2 0 5 a |3は、 メ ッセージダイジュス トを作成しない。 送信者 ·通信 ·受信者 情報取得部 2 0 5 b /3は、 上述した送信者 ·通信 ·受信者情報取得部 1 0 3 b |3 と同様にして、送信者情報、通信情報および受信者情報を取得する。 デジタル署名確認部 2 0 5 c ]3は、 送信者 （端末 1 0 0 ]3 ) の公開鍵を用 いて、 受信内容確認情報 1 3 /3に対するデジタル署名を確認する。 次に、 上述した一実施形態による情報改竄検知装置の動作について図 1 3〜図 1 6に示すフローチャートを参照しつつ説明する。 図 1 3は、 図 1 2に示す受信内容確認情報確認部 1 0 3 i3の動作を説明するフローチヤ一 トであり、 図 1 4は、 図 1 2に示す送信内容確認情報作成部 1 0 4 の動 作を説明するフローチャートである。 また、 図 1 5は、 図 1 2に示す受信 内容確認情報作成部 2 0 2 ]3の動作を説明するフローチヤ一トであり、 図 1 6は、 図 1 2に示す送信内容確認情報確認部 2 0 5 /3の動作を説明する フローチヤ一 トである。 44 図 1 2において、 端末 1 0 0 |3における転送情報 1 1 |3が情報送信部 1 0 1 j3によりネッ 卜ワーク N )3を介して端末 2 0 0 へ送信されると、 該 転送情報 1 1 )3は、端末 2 0 0 の情報受信部 2 0 1 により受信される。 これにより、 端末 2 0 0 βの受信内容確認情報作成部 2 0 2 /3は、 図 1 5 に示すフローチヤ一卜に従って受信内容確認情報 1 3 βを生成する。 具体的には、 図 1 5に示すステップ S E 1 βでは、 受信内容確認情報作 成部 2 0 2 iSは、 受信内容 （転送情報 1 1 /3 ) を入力する。 これにより、 ステップ S E 2 βでは、 メ ッセージダイジエス 卜作成部 2 0 2 a i3は、 受 信内容 （転送情報 1 1 ]3 ) をハッシュ関数で圧縮してメッセージダイジヱ ス ト （図 1 1 ：転送情報 MD J3 1 2 b β ) を作成する。 なお、 図 1 5に示 す例では、 ステップ S Ε 2 ]3の処理を実行することなく 、 ステップ S E 1 ]3からステップ S E 6 jSへ進んでもよい。 また、 ステップ S Ε 3 )3〜S Ε 5 j3では、 受信内容確認情報作成部 2 0 2 |3は、 送信者情報 （送信者名、 I D、 公開鍵 I D、 メールア ドレス、 電 子証明書等）、 受信者情報 （受信者名、 I D、 公開鍵 I D、 メールァドレ ス、 電子証明書等）、 通信情報 （送信時間、 受信時間、 通信方式、 通信 I D等） を転送情報 1 1 ]3から取り込む。 これにより、 ステップ S E 6 /3では、 送信者 ·通信 ·受信者情報取得部 2 0 2 b ]3は、 ステップ S E 3 j3〜S E 5 /3で入力された送信者情報、 受 信者情報および通信情報を取得した受信内容確認情報作成部 2 0 2 |3は、 上述した受信内容 （転送情報 1 1 3 ) と、 転送情報 MD 1 2 b )3、 送 信者情報、 受信者情報、 通信情報等の各情報 とを統合する。 ここで、 情 報の統合とは、 ハッシュ関数で圧縮された転送情報 MD 1 2 b jSの全部 4δ または一部と、 送信者情報における送信者名、 I D等、 受信者情報におけ る受信者名、 I D等、 通信情報における送信時間、 受信時間等のうち 1つ または複数の情報とを組み合わせることをいう。 次に、 ステップ S E 7 i3では、 メッセージダイジェス ト作成部 2 0 2 a |3は、 ステップ S E 6 ]Sで統合された情報をハッシュ関数で圧縮すること により、 メッセージダイジェストを作成する。 次いで、 ステップ S E 8 3 では、 デジタル署名付加部 2 0 2 c は、 ステップ S E 7 で作成された メッセージダイジエストを受信者の秘密鍵で暗号化することにより、 メッ セージダイジェス トに対して、 デジタル署名を付加する。 そして、 ステツ プ S Ε 9 |3では、 受信内容確認情報作成部 2 0 2 βは、 各情報を統合化す ることにより、 図 1 1に示す受信内容確認情報 1 3 ]3を作成した後、 これ を情報送信部 2 0 3 /3へ出力する。
また、 メッセ一ジダイジェス ト作成部 2 0 2 a /3は、 必要に応じて転送 情報 M D β 1 2 h βを送信内容確認情報確認部 2 0 5 ]3のメ ッセージダイ ジェス ト作成 '取得部 2 0 5 a /3へ出力する。 この場合、 メ ッセージダイ ジエス ト作成 .取得部 2 0 5 a /3は、 メッセ一ジダイジエス 卜の作成を行 うことなく、 上記転送情報 M D β 1 2 b βを取得する。 そして、 上記受信内容確認情報 1 3 は、 情報送信部 2 0 3 jSによりネ ッ トワーク N |3を介して端末 1 0 0 ]3へ送信された後、 端末 1 0 0 ]3の情 報受信部 1 0 2 ]3により受信される。 これにより、 端末 1 0 0 0の受信内 容確認情報確認部 1 0 3 ι3は、 図 1 3に示すフローチャートに従って、 受 信内容確認情報 1 3 | の内容を確認することにより、 改竄を検知する。 具体的には、 図 1 3に示すステップ S C 1 βでは、 受信内容確認情報確 46 認部 1 0 3 /3は、 情報受信部 1 ◦ 2 βにより受信された受信内容確認情報 1 3 ]3を入力した後、 ステップ S C 2 j3へ進む。 ステップ S C 2 |3では、 メッセージダイジエス ト作成部 1 0 3 a ]3は、 受信者の公開鍵を用いて受 信内容確認情報 1 3 βを複号化することにより、 メッセージダイジエス ト (図 1 1 ：転送情報 MD β 1 2 c β ) を作成 （取得） する。 そして、 ステップ S C 3 |3では、 デジタル署名確認部 1 0 3 c は、 受 信者 （端末 2 0 0 i3 ) の公開鍵を用いて、 受信内容確認情報 1 3 i3が受信 者によりデジタル署名されたものであるか否かを確認する。 ここで、 受信 内容確認情報 1 3 が受信者 （端末 2 0 0 /3 ) の公開鍵で複号化できた場 合、 受信内容確認情報 1 3 |3は、 受信者によりデジタル署名されたもので あり、 一方、 受信内容確認情報 1 3 ;3が受信者の公開鍵で複号化できなか つた場合、 受信内容確認情報 1 3 |3は受信者によりデジタル署名されなか つたものである。 次に、 ステップ S C 4 3では、 受信内容確認情報確認部 1 0 3 J3は、 ス テツプ S C 3 ]3の確認結果から、 受信内容確認情報 1 3 βのデジタル署名 が受信者 （端末 2 0 0 ) のデジタル署名であるか否かを判断し、 同判断 結果が 「NO」 の場合、 改竄もしくは通信エラ一が発生したものとする。 一方、 ステップ S C 4 /3の判断結果が 「Y E S」 の場合、 受信内容確認情 報確認部 1 0 3 /3は、 ステップ S C 5 3へ進む。 ステップ S C 5 βでは、 受信内容確認情報 1 3 βに含まれている各種情 報を分類する。 ここで、 上記各種情報としては、 受信情報内容、 前述した 送信者情報、 受信者情報、 通信情報、 メ ッセージダイジ ス ト （転送情報 MD β 1 2 c j3 ) 等がある。 47
また、 受信内容確認情報確認部 1 0 3 i3は、 ステップ S C 6 (3へ進み、 転送情報 1 1 )3、 送信者が転送した、 通信に関する送信者情報、 通信情報、 受信者情報等を入力する。 次に、 ステップ S C 7 では、 受信内容確認情 報確認部 1 0 3 ]3のメ ッセ一ジダイジエスト作成部 1 0 3 a は、 転送情 報 1 1 13をハッシュ関数で圧縮して転送情報 M D β 1 2 a β (図 1 1参 照） を作成する。 そして、 受信内容確認情報確認部 1 0 3 ]3は、 ステップ S C 9 jS〜S C 1 2 で受信内容と送信内容とを比較することにより、 受信内容の検証を 情報毎に行う。 そして、 ステップ S C 1 3 ]3では、 受信内容確認情報確認 部 1 0 3 3は、 上記ステップ S C 9 ]3〜S C 1 2 j3の検証結果を受けて、 受信内容が送信内容と相違ないか否かを判断し、 同判断結果が 「N O」 の 場合、 改竄もしくは通信エラーが発生しているものとする。 一方、 受信内 容確認情報確認部 1 0 3 ]3は、受信内容が送信内容と相違していない場合、 S C 1 3 ]3の判断結果を 「Y E S」 として、 改竄が発生していないものと する。 次いで、 送信内容確認情報作成部 1 0 4 ]3は、 図 1 4に示すフロ一チヤ —卜に従って、 送信内容確認情報 1 4 (図 1 1参照） を作成する処理を 実行する。 すなわち、 送信内容確認情報作成部 1 0 4 ]3は、 図 1 4に示す ステップ S D 1 βで受信内容確認情報 1 3 βを入力した後、 ステップ S D 2 ]3で受信内容確認情報承認情報を生成する。 ここで、 受信内容確認情報 承認情報とは、 受信内容確認情報確認部 1 0 3 が受信内容確認情報 1 3 ]3の内容を承認 （確認） した旨を示す情報である。 この承認 （確認） した 旨を示す情報は、 承認した時間、 端末、 承認者 （一実施形態では送信者） 48 . に関する情報を元に生成される。 次いで、 ステップ S D 3 ]3では、 送信内容確認情報作成部 1 0 4 3は、 受信内容確認情報 1 3 βと受信内容確認情報承認情報とを統合する。次に、 ステップ S D 4 ]3では、 メッセージダイジェス ト作成部 1 0 4 a )3は、 ス テツプ S D 3 βにおいて統合された情報のメッセージダイジエス トを取得 した後、 ステップ S D 5 3へ進む。 ステップ S D 5 |3では、 デジタル署名 付加部 1 0 4 c J3は、 送信者 （端末 1 0 0 /3 ) の秘密鍵により暗号化する ことにより、 メッセージダイジエス 卜に対してデジタル署名を行う。 そして、 ステップ S D 6 |3では、 送信内容確認情報作成部 1 0 4 /3は、 ステップ S D 3 における各種情報とステップ S Ό 5 βにおいてデジタル 署名されたメッセージダイジェス トとを統合化する。 これにより、 送信内 容確認情報作成部 1 0 4 βにおいては、 送信内容確認情報 1 4 βが作成さ れ、 該送信内容確認情報 1 4 ]3は、 情報送信部 1 0 5 3へ出力される。 そして、 上記送信内容確認情報 1 4 )3は、 情報送信部 1 0 5 /3により、 ネッ トワーク Ν ;3を介して端末 2 0 0 へ送信された後、 端末 2 0 0 ι3の 情報受信部 2 0 4 ;3により受信される。 これにより、 端末 2 0 0 /3の送信内容確認情報確認部 2 0 5 /3は、 図 1 6に示すフローチヤ一卜に従って、 送信内容確認情報 1 4 βの確認を実行 する。
具体的には、 図 1 6に示すステップ S F 1 3では、 送信内容確認情報確 認部 2 0 5 /3は、 情報受信部 2 0 4 により受信された送信内容確認情報 1 4 ]3を入力した後、 ステップ S F 2 0へ進む。 ステップ S F 2 /3では、 49 . メッセージダイジ ス 卜作成 ·取得部 2 0 5 a は、 送信者 （端末 1 0 0 β ) の公開鍵を用いて送信内容確認情報 1 4 βを復号化することにより、 メッセ一ジダイジェス トを作成 （取得） する。 そして、 ステップ S F 3 /3では、 デジタル署名確認部 2 0 5 c /3は、 送 信者 （端末 1 0 0 /3 ) の公開鍵を用いて、 送信内容確認情報 1 4 |3が送信 者によりデジタル署名されたものであるか否かを確認する。 ここで、 送信 内容確認情報 1 4 βが送信者 （端末 1 0 0 ]3 ) の公開鍵で複号化できた場 合、 送信内容確認情報 1 4 )3は、 送信者によりデジタル署名されたもので あり、 一方、 送信内容確認情報 1 4 ]3が送信者の公開鍵で複号化できなか つた場合、 送信内容確認情報 1 4 は送信者によりデジタル署名されなか つたものである。 次に、 ステップ S F 4 では、 送信内容確認情報確認部 2 0 5 /3は、 ス テツプ S F 3 |3の確認結果から、 送信内容確認情報 1 4 のデジタル署名 が送信者 （端末 1 0 0 /3 ) のデジタル署名であるか否かを判断し、 同判断 結果が 「Ν Ο」 の場合、 改竄もしくは通信エラーが発生したものとする。 一方、 ステップ S F 4 の判断結果が 「Y E S」 の場合、 送信内容確認情 報確認部 2 0 5 )3は、 ステップ S F 5 |3へ進む。 ステップ S F 5 /3では、 送信内容確認情報 1 4 βに含まれている各種情 報を分類する。 ここで、 上記各種情報としては、 受信情報内容、 前述した 送信者情報、 受信者情報、 通信情報、 メ ッセージダイジェス ト等がある。 また、 送信内容確認情報確認部 2 0 5 は、 ステップ S F 6 ]3へ進み、 受信した転送情報 1 1 ]3、 送信者が転送した、 通信に関する送信者情報、 50 通信情報、 受信者情報等を入力する。 次に、 ステップ S F 7 i3では、 送信 内容確認情報確認部 2 0 5 ]3のメ ッセージダイジエス ト作成 ·取得部 2 0 5 a (3は、 転送情報 1 1 ]3をハッシュ関数で圧縮して転送情報 M D ]3 1 2 b β (メッセージダイジェス ト） を作成する。 ただし、 メッセージダイジ エス ト作成 ·取得部 2 0 5 a /3は、 メッセ一ジダイジエス ト作成部 2 0 2 a ]3から転送情報 M D ]3 1 2 b /3を取得した場合、 上記作成動作を行わな レ、。 そして、 送信内容確認情報確認部 2 0 5 /3は、 ステップ S F 9 /3〜S F 1 2 βで受信内容と送信内容とを比較することにより、 受信内容の検証を 情報毎に行う。 そして、 ステップ S F 1 3 /3では、 送信内容確認情報確認 部 2 0 5 βは、 上記ステップ S F 9 j3〜S F l 2 βの検証結果を受けて、 受信内容が送信内容と相違ないか否かを判断し、 同判断結果が 「Ν Ο」 の 場合、 改竄もしくは通信エラーが発生しているものとする。 一方、 送信内 容確認情報確認部 2 0 5 0は、受信内容が送信内容と相違していない場合、 S F 1 3 0の判断結果を 「Y E S」 として、 改竄が発生していないものと する。 以上説明したように、 上述した一実施形態による情報改竄検知装置によ れば、 受信内容確認情報 1 3 β、 送信内容確認情報 1 4 0を用いて改竄検 知を行うように構成したので、 受信した情報を復号化する権利を有しない 端末であっても、 情報の改竄を検知することができる。 以上第 2の実施形態について詳述してきたが、 具体的な構成はこの実施 形態に限定されるものではない。 例えば、 上述した一実施形態による情報 改竄検知装置においては、 上述した機能を実現するための改竄検知プログ 51 ラムを、 コンピュータ読み取り可能な記録媒体に記録して、 この記録媒体 に記録された改竄検知プログラムをコンピュータシステムに読み込ませて 実行させることにより、 情報の改竄検知をおこなってもよい。 また、 上記改竄検知プログラムは、 フロッピ一ディスク、 C D— R O M 等の可搬媒体や、 ハードディスク等の記憶装置等に、 その全体あるいは一 部が記録され
、 あるいは記憶されている。 その改竄検知プログラムは、 コンピュータに より読みとられて、 動作の全部あるいは一部が実行される。
また、 ここでいう記録媒体は、 光磁気ディスク等のように改竄検知プロ グラムを静的に記録しているものに限らず、 インターネッ トの専用線、 電 話回線等の通信回線を通して改竄検知プログラムを送信する場合の通信回 線のように、短時間の間、動的に改竄検知プログラムを保持しているもの、 その場合のサーバやコンピュータ内部のメモリのように、 一定時間改竄検 知プログラムを保持しているものも含むものとする。 以上説明したように、 第 2の実施形態の発明によれば、 受信内容確認情 報、 送信内容確認情報を用いて改竄検知を行うように構成したので、 受信 した情報を復号化する権利を有しない端末であっても、 情報の改竄を検知 することができる。
[第 3の実施形態]
第 3の実施形態の発明は、 情報の暗号化複号化を行なう暗号化装置、 復 号化装置、 方法及びその記録媒体に関する。 第 3の実施形態のの発明に関し、従来以下説明する技術が知られている。 52 一般に情報の伝達に際し、 この情報に秘匿性が要求される場合がある。 そこでさまざまな暗号化方式が考案されている。 ここで従来の暗号化 ·著 名方式を用いた暗号化装置の 1例の動作フローチヤ一トを図 3 3に示す。 この例の方式では、 公開鍵喑号方式と共通鍵暗号方式を組み合わせ利用し ている。
まず、 暗号化装置は、 送信者による共通鍵の入力か、 または暗号化装置 側で乱数を発生させ共通鍵を生成し共通鍵を取得する （ステップ S 1 5 1 y )0
次に、 公開鍵暗号方式を利用し受信者の公開鍵を用いて共通鍵を暗号化 し暗号化鍵とする （ステップ S 1 5 2 y)。
次に共通鍵暗号化方式を利用し、 平文を共通鍵を用いて暗号化し暗号文 を生成する （ステップ S 1 5 3 7 )o
さらにハッシュ関数を用いて平文を圧縮することでメッセ一ジダイジェ ス トである MD γを作成する （ステップ S 1 5 4 y )。
そして、 この MD 7を送信者の秘密鍵で暗号化することでデジタル署名 を付加する （ステップ S 1 5 5 y)。
送信者は、 以上で生成した暗号化鍵と暗号文とデジタル署名をネッ トヮ —ク等を介して受信者に送信する。 図 3 4に、 上記暗号化 ·デジタル署名方式に対応する複号化方式を用い た復号化装置の動作フローチヤ一トを示す。
複号化装置は、 暗号化鍵と暗号文とデジタル署名を受信すると、 まず受 信者の秘密鍵を利用して暗号化鍵を復号化し共通鍵を得る （ステップ S 1 6 1 γ )。
そしてこの共通鍵を用いて暗号文を複号化し平文を得る （ステップ S 1 6 2 γ )c 53 . 次に復号化して得た平文をハッシュ関数で圧縮しメッセ一ジダイジエス MD
' γを生成する （ステップ S 1 63 γ)。
さらに受信したメッセージダイジエス MD γのデジタル署名を送信者 の公開鍵で複号化し MD yを得る （ステップ S 1 647 )0
次に、 この MD Yと先の MD ' γを比較し、 元の平文が改竄されていな いかの検証を行なっている。 この方式の場合、 著名検証により平文への著 名者を本人確認できる利点がある。
次に、 特開平 8— 1 5 6 964に開示されている暗号化方式では、 平文 であるデータパーッが複数からなる情報を上記方式で暗号化している。 図 3 5に η個のデータパーツ （平文） からなる情報と、 この情報から生成さ れる暗号化情報の構成を示している。 この場合の暗号化情報は、 各データ パ一ッに対応する暗号化鍵とデータパーツの暗号文とデータパーツのデジ タル署名を含んでいる。 一例として 6 9バイ トのデータパーツに対して付 加されるデジタル署名のサイズは、 23 2 9バイ トである。 デジタル署名 のサイズには下限がありデータパーツのサイズが小さくてもデジタル署名 はあるサイズ以上の大きさをもつ。 例えば、 6 9バイ トのデータパーツ 1 00個から構成される情報に対し、 改竄防止のためにデジタル署名を付加 すると、 23 29 x 1 00 = 23 2 900バイ トの情報が付加されること になる。
次に、 特開平 9一 7 1 3 88に開示されている暗号化方式では、 複数の データパーツからなる情報に対して、 各データパーツのメッセージダイジ エス トをまとめてデジタル署名し暗号化している。 図 3 6に η個のデータ パーツ （平文） からなる情報と、 この情報から生成される暗号化情報の構 54 . 成を示している。 複数のデータパーツからなる情報を暗号化する場合、 例えば特開平 8— 1 5 6 9 6 4に開示されている方式では、 データのオーバ一へッ ドが大き くなり、 暗号化情報の伝送により多くの時間がかかることや、 記憶装置等 の資源を多く必要とする等の問題がある。 また、 特開平 9— 7 1 3 8 8に 開示されている方式では、 各データパーツのメッセージダイジエストをま とめてデジタル署名しているので、 すべての平文がそろわないとデジタル 署名の確認ができず、 一部のデータパーツの参照のみ許可されているユー ザがいる場合、 データパーツの改竄を検証することができない点や、 各デ —タパ一ッを同時に変更できない等の問題がある。 本発明は、 上記の点に鑑みてなされたもので、 複数のデータパーツ （平 文） を含む情報を暗号化した暗号化情報のオーバーへッ ドをより少なくで き、 また複数のユーザで利用可能であるとともに、 各データパーツの改竄 検証と同時変更も可能な暗号化装置、 復号化装置、 方法及びその記録媒体 を提供するものである。 以下、 第 3の実施形態を図面を参照して説明する。
図 1 9は、 本発明の一実施形態である暗号化装置、 復号化装置の構成を 示すブロック図である。 なお、 本実施の形態では、 暗号化装置と復号化装 置とがー体となった暗号化復号化装置として説明する。 本実施形態の暗号化複号化装置 1 0 T/は、 鍵暗号化部 1 1 γと、 鍵復号 化部 1 2 γと、 暗号化部 1 3 γ と、 復号化部 1 4 γとを備える。 鍵暗号化 部 1 1 γは、 共通鍵取得部 1 5 γ と共通鍵暗号化部 1 6 γと第 1共通鍵改 竄検出情報作成部としての共通鍵改竄検出情報作成部 1. 7 γからなる。 鍵 複号化部 1 2 γは、 共通鍵復号化部 1 8 γと第 2共通鍵改竄検出情報作成 部としての共通鍵改竄情報作成部 1 9 γと第 1改竄検証部と しての改竄検 証部 2 0 γからなる。 暗号化部 1 3 γは、 データ暗号化部 2 1 γと第 1デ ータ改竄検出情報作成部としてのデータ改竄検出情報作成部 2 2 yからな る。 復号化部 1 4 Vは、 データ復号化部 2 3 y と第 2データ改竄検出情報 作成部としてのデータ改竄検出情報作成部 2 4 7 と第 2改竄検証部として の改竄検証部 2 5 γからなる。 共通鍵取得部 1 5 γは、暗号化に使用する共通鍵を取得または生成する。 共通鍵の生成には、 一例として乱数生成装置等を利用し生成させる。 共通 鍵暗号化部 1 6 γは、 R S Α方式や楕円喑号方式等の公開鍵喑号方式を利 用して共通鍵を暗号化する。 暗号化に使用する公開鍵は、 情報を共有する メンバ一の公開鍵を使用する。 例えば共有メンバーが 3人の場合、 3人が 所持する公開鍵を用いて共通鍵を暗号化し、 3つの暗号化鍵を作成する。 共通鍵改竄検出情報作成部 1 7 γは、 共通鍵の正当性 （ 1 . 改竄されてい ない、 2 . 正当なユーザによって作成されている等） を検証するために利 用する鍵情報を作成する。 一例として、 共通鍵を M D 5、 S H A— 1等の ハッシュ関数で圧縮して共通鍵のメッセージダイジエス M D yを作成し、 この M D に共通鍵作成者の秘密鍵を用いてデジタル署名を行なったもの を鍵情報として利用できる。 デジタル署名の作成 ·検証には、 公開鍵暗号 方式の他、 D S A等のデジタル署名方式等を利用してよい。 共通鍵複号化部 1 8 γは、 共通鍵暗号化部 1 6 γにより暗号化された喑 号化鍵を公開鍵暗号方式を用いて複号化する。 複号化に用いる秘密鍵は、 復号化を行なうユーザの秘密鍵を用いる。 共通鍵改竄検出情報作成部 1 9 56 yは、 共通鍵の正当性確認を行なうために利用する共通鍵改竄検出情報を 作成する。 例えば、 共通鍵復号化部 1 8 γで復号化された共通鍵をハツシ ュ関数で圧縮したメ ッセ一ジダイジェス ト M D ' γを作成する。 改竄検証 部 2 0 γは、 鍵情報 （一例として M D T ) と共通鍵改竄検出情報作成部 1 9 γで作成した共通鍵改竄検出情報 （一例として M D ' y ) を比較検証す ることにより、 共通鍵の正当性を確認する。 共通鍵の正当性を確認するに あたり、 共通鍵作成者自身の正当性確認も必要となるが、 別途定められる ものである。 データ暗号化部 2 1 γは、 データパーツ （平文） を共通鍵暗号方式を利 用して暗号化し、 暗号文を生成する。 暗号化に使用する共通鍵は、 初めて 暗号化する場合には共通鍵取得部 1 5 γで取得または生成された共通鍵を 用い、 既存の暗号化情報を利用する場合には、 共通鍵複号化部 1 8 γによ り復号化された共通鍵を用いる。 データ改竄検出情報作成部 2 2 は、 デ ータパーツが改竄されていないか検証するための第 1データ改竄検出情報 を作成する。 例えば、 ハッシュ関数を用いてデータパーツを圧縮したメッ セージダイジェス トや、 データパーツから抽出した部分情報、 I D番号等 などを第 1データ改竄検出情報として利用できる。 データ複号化部 2 3 は、共通鍵暗号方式を用いて暗号文を復号化する。 復号化に用いる共通鍵は、 共通鍵復号化部 1 8 により複号化された共通 鍵を用いる。 データ改竄検出情報作成部 2 4 γは、 第 1データ改竄検出情 報に対応しデータパーツが改竄されていないか検証するための第 2データ 改竄検出情報を作成する。 例えば、 データ復号化部 2 3 yで複号化された 元のデ一タパ一ッをハッシュ関数を用いて圧縮して作成したメッセ一ジダ イジ-ス トや、 データパーツから抽出した部分情報、 I D番号等などを第 57
2データ改竄検出情報として利用できる。 改竄検証部 2 5 γは、 第 1デ一 タ改竄検出情報と第 2データ改竄検出情報を比較検証することにより、 復 号化した元のデータパーツの正当性を確認する。 なお、 共通鍵暗号化部 1 6 Vとデータ暗号化部 2 1 γを、 同一の装置で で実現してもよい。 また、 共通鍵複号化部 1 8 γとデータ復号化部 2 3 γ を、 同一の装置で実現してもよい。 また、 共通鍵改竄検出情報作成部 1 7 γと 1 9 γ、 または、 データ改竄検出情報作成部 2 2 γ と 2 4 γを、 同一 の装置でで実現してもよい。 同様に、 共通鍵改竄検出情報作成部 1 7 γと 1 9 y及びデータ改竄検出情報作成部 2 2 γ と 2 4 yのすベてを、 同一の 装置でで実現してもよい。 また、改竄検証部 2 0 yと改竄検証部 2 5 γを、 同一の装置でで実現してもよい。 また、 本実施の形態の暗号化復号化装置 を、 単一の装置としてではなく、 各部が独立した装置でとして実現し利用 してもよい。 なお、 請求項 5 1および請求項 5 2に記載の暗号化装置は、 鍵暗号化部 1 1 Ίと暗号化部 1 3 yとから構成できる。 また、 請求項 5 3 に記載の暗号化装置は、 鍵暗号化部 1 1 Ίと暗号化部 1 3 γ と鍵複号化部 1 2 とから構成できる。 請求項 5 4および請求項 5 5に記載の複号化装 置は、 鍵複号化部 1 2 と復号化部 1 4 γとから構成できる。 図 2 0に、 本実施形態の暗号化複号化装置 1 0 γの一利用形態を示す。 本利用形態では、 ネッ トワークに接続可能なサーバや他端末装置等から なる情報保管装置 3 0 γと、 暗号化復号化装置 1 0 γを備える端末装置 3 1 7とがネッ トワークを介して接続されている。 情報保管装置 3 0 γは、 ハードディスク、 光磁気ディスク等の不揮発性の記録装置を備え、 暗号化 情報として、 暗号文、 データ改竄検出情報、 暗号化鍵、 鍵情報および関連 情報を保存可能とする。 また、 端末装置 3 1 γには、 周辺機器として入力 58 . 装置、 表示装置等 （いずれも図示せず） が接続されるものとする。 ここで、 入力装置とはキーボード、 マウス等の入力デバイスのことをいう。 表示装 置とは C RT (C a t h o d e R a y T u b e ) や液晶表示装置等のこ とをいう。 なお、 暗号化情報をローカルな端末装置 3 1 γに保管し、 スタ ンドアローンで利用してもよい。 次に、 このように構成された利用形態における本実施形態の暗号化復号 化装置 1 0 Ίの動作について説明する。
まず、 最初のデ一タパ一ッを喑号化する際の暗号化復号化装置 1 の 動作を図 2 1に示す動作フローチャートを参照して説明する。 なお、 下記 の説明における動作手順は、 本実施形態の動作の一例であり、 その処理の 順序は固定されるものではなく他の順序で実施されてもよい。 始めに、 共通鍵取得部 1 5 γが、 暗号化復号化装置 1 0 γの外部からの 入力により共通鍵を取得するかまたは共通鍵の生成を行なう （ステップ S 3 0 1 y )0 それから共通鍵暗号化部 1 6 γは、 ネッ トヮ一クを介して予め取得して いる利用者の公開鍵を利用して共通鍵を暗号化した暗号化鍵を生成する (ステップ S 3 0 2 y )。 さらに、 共通鍵改竄検出情報作成部 1 7 γは、 共通鍵作成者の秘密鍵等 の共通鍵作成者に関する情報を共通鍵改竄検出情報としての鍵情報として 作成する （ステップ S 3 0 3 T )。 データ暗号化部 2 1 γはデータパーツ 1 γ (平文） を暗号化し暗号文 1 59
Ύを生成する （ステップ S 3 0 4 y ), さらに、 データ改竄検出情報作成部 2 2 γは、 データパーツ l yからデ ータパーツ 1 γに関する情報であるデータ改竄検出情報 1 yを作成する (ステップ S 3 0 5 ）。 なお、 データパーツが n個からなる場合、 ス テツプ S 3 0 4 yからステップ S 3 0 5 yの処理を n回繰り返す。 そして暗号文 1、 2、 '··、 n、 データ改竄検出情報 1、 2、 ···, n、 鍵 情報、暗号化鍵の組を暗号化情報として情報保管装置 3 0 yへ送信する（ス テツプ S 3 0 6 y)。 なお、 上記説明は利用者が 1人で、 使用する暗号化鍵が 1種類の場合で ある。 暗号化情報を共有する利用者が複数 （例えば m人） である場合は、 ステップ S 3 0 2 γで、 各利用者毎の公開鍵を用いて m種の暗号化鍵を生 成させる。 すなわち、 利用者毎に対応する暗号化鍵が生成されることにな る。
図 2 2に、 暗号化前の情報の構成と、 暗号化された暗号化情報の構成を 示す。 ここでは、 暗号化前のデータパーツ 1、 2、 ··■、 n力ゝら、 暗号化情 報として、 暗号文 1、 2、 ···、 nとデータ改竄検出情報 1、 2、 ···, nと 暗号化鍵 1、 2、 ···、 mと鍵情報が作成されることを示している。 次に、 複数 （n個） のデータパーツの暗号文を含む暗号化情報を復号化 する際の暗号化復号化装置 1 0 Ίの動作を図 2 3の動作フローチヤ一トを 参照して説明する。
なおこの処理は、 暗号化鍵を作成する際に用いた公開鍵と対をなす秘密 鍵を所有する者が行なえるものである。 ' 60
まず、 暗号化復号化装置 1 0 γは情報保管装置 3 0 γに記憶されている 暗号化情報を取得する （ステップ S 5 0 1 y )。 なお、 暗号化情報に含ま れる暗号化鍵は、 ユーザ名やユーザ I D等により対応づけられ、 利用者に 対応した暗号化鍵が情報保管装置 3 0 yから暗号化復号化装置 1 0 γに送 られるものとする。 そして共通鍵復号化部 1 8 γは、 利用者の秘密鍵を用いて暗号化鍵を復 号化し共通鍵を得る （ステップ S 5 0 2 y )。 ここで利用者の秘密鍵は、 予め入力されているものとする。 次に、 共通鍵改竄検出情報作成部 1 9 Ύは、 ステップ S 5 0 2 γで得た 共通鍵から共通鍵改竄検出情報を作成する （ステップ S 5 0 3 γ )。 そして改竄検証部 2 0 γは、 取得した鍵情報と共通鍵改竄検出情報を比 較検証し鍵作成者の正当性を検証する （ステップ S 5 0 4 y ) 0 この場合、 2つの情報が一致することで鍵作成者の正当性を判断できる。 ステップ S 5 0 4 γで、 鍵作成者が正当であると判断された場合、 η個 の暗号文と η個のデータ改竄検出情報の組を順に以下の処理を行なう。 まず、 データ復号化部 2 3 γは暗号文を共通鍵を用いて複号化する （ス テツプ S 5 0 5 y ) c そして、 データ改竄検出情報作成部 2 4 は、 復号化したデータパーツ を用いてデータ改竄検出情報を作成する （ステップ S 5 0 6 y ) c なお、 ここで作成したデータ改竄検出情報を第 1データ改竄検出情報と呼び、 暗 61 号化情報として保持されているデータ改竄検出情報を第 2データ改竄検出 情報と呼ぶことにする。 次に改竄検証部 2 5 γは、 作成された第 1データ改竄検出情報と暗号化 情報の一部である第 2データ改竄検出情報を比較し改竄が行われていない か検証する （ステップ S 5 0 7 y)。 2つの情報が一致することで改竄が 行われていないことが検証される。 ステップ S 50 7 γで、 改竄がないと判断されれば複号化したデータパ —ッ （平文） を出力する （ステップ S 50 8 y)。 なお、 以上の説明では、 ユーザ名やユーザ I D等と暗号化鍵を対応づけ ることで、 鍵複号化部 1 2 τ /が利用者に対応する暗号化鍵のみを用いるよ うにしている。 複数の暗号化鍵がある （すなわち、 暗号化情報を共有する 利用者が複数存在する） 場合、 利用者に対応する暗号化鍵を得るその他の 方法として、 上記ステップ S 5 0 2 T 〜S 504 yを以下のようにする。 まず、 ステップ S 5 0 2 yにおいてすべての暗号化鍵を復号化する。 ステ ップ S 50 2 γで複数の暗号化鍵を複号化した場合、 正式でないものも含 めて複数の共通鍵が生成される。 ステップ S 5 0 3 yでは、 ステップ S 5 027で生成されたすベての共通鍵に対し共通鍵改竄検出情報を作成する。 次に、 ステップ S 504 /で、 各共通鍵改竄検出情報と鍵情報とを比較検 証する。 すべての組み合わせが異なるとき改竄が行われていることがわか り、 一致するものがあれば対応する共通鍵が正式の共通鍵であることがわ かる。 次に、 上述した、 データバ一ッ 1、 2、 ···、 nから暗号化情報を作成し 62 情報保管装置 3 0 /に転送した段階から、 ここではさらに上記の暗号化情 報に情報を追加する際の暗号化複号化装置 1 0 7の動作を図 2 4に示す動 作フローチヤ一トを参照して説明する。 先ず、 暗号化情報が保管されている情報保管装置 3 0 γから暗号化鍵と 鍵情報を取得する （ステップ S 6 0 1 γ )。 なお、 暗号化情報に含まれる 暗号化鍵は、 ユーザ名やユーザ I D等により対応づけられ、 利用者に対応 した暗号化鍵が情報保管装置 3 0 γから暗号化復号化装置 1 0 γに送られ るものとする。 そして、 共通鍵複号化部 1 8 γは、 利用者の秘密鍵を用いて利用者に対 応する暗号化鍵を復号化する （ステップ S 6 0 2 y )。 ここで利用者の秘 密鍵は、 予め入力されているものとする。 次に、 共通鍵改竄検出情報作成部 1 9 γは、 ステップ S 6 0 2 γで得た 共通鍵から共通鍵改竄検出情報を作成する （ステップ S 6 0 3 ) 0 改竄検証部 2 0 γは、 先の鍵情報と共通鍵改竄検出情報が一致するか比 較検証し、 鍵作成者の正当性を検証する （ステップ S 6 0 4 ）。 この場 合、 2つの情報が一致することで鍵作成者の正当性を判断できる。 ステップ S 6 0 4 γで、 鍵作成者が正当であると判断された場合、 デー タ暗号化部 2 1 γは追加するデータパーツ η + 1を暗号化し暗号文 η + 1 を生成する （ステップ S 6 0 5 y ) c さらにデータ改竄検出情報作成部 2 2 γはデータパーツ η + 1から改竄 63 . 検出情報 n + 1を作成する （ステップ S 6 0 6 γ)。
なお、 追加するデータパーツが L個からなる場合、 ステップ S 6 0 5 y からステップ S 6 0 6 yの処理を L回繰り返す c そして暗号文 n + 1、 n + 2、 ··'、 n + Lと改竄検出情報 n + 1、 n + 2、 ···
、 n + Lを情報保管装置 3 0 T に転送し暗号化情報として追加保管する（ス テツプ S 6 0 7 y )。 なお、 以上の説明では、 ユーザ名やユーザ I D等と暗号化鍵を対応づけ ることで、 鍵復号化部 1 2 γが利用者に対応する暗号化鍵のみを用いるよ うにしている。 複数の暗号化鍵がある （すなわち、 暗号化情報を共有する 利用者が複数存在する） 場合、 利用者に対応する暗号化鍵を得るその他の 方法として、 上記ステップ S 6 0 2 y〜S 6 0 4 yを以下のようにする。 まず、 ステップ S 6 0 2 γにおいてすべての暗号化鍵を復号化する。 ステ ップ S 6 0 2 7で複数の暗号化鍵を復号化した場合、 正式でないものも含 めて複数の共通鍵が生成される。 ステップ S 6 0 3 yでは、 ステップ S 6 0 2 7で生成されたすベての共通鍵に対し共通鍵改竄検出情報を作成する。 次に、 ステップ S 6 0 4 で、 各共通鍵改竄検出情報と鍵情報とを比較検 証する。 すべての組み合わせが異なるとき改竄が行われていることがわか り、 一致するものがあれば対応する共通鍵が正式の共通鍵であることがわ かる。
図 2 5に、 暗号化情報の追加前の構成と、 追加後の構成を示す。 ここで は、 暗号化情報として、 暗号文 n + 1 、 n + 2、 ··■、 n + Lとデータ改竄 検出情報 n + 1、 n + 2、 ···、 n + Lがもとの暗号化情報に追加されてい ることを示している。 64
次に、 情報保管装置 3 0 γに記憶されている暗号化情報を共有している チームに、 共有メンバーを追加する際の暗号化復号化装置 1 0 γの動作を 図 2 6に示す動作フローチャー トを参照して説明する。 ここでは、 共有メ ；— Α、 Βが所属しているチームに、 共有メンバー Βが、 新しい共有メ ；—として共有メンバー Cを追加する場合を説明する。 まず、 共有メンバ一 Βの操作により、 暗号化複号化装置 1 0 yは情報保 管装置 3 0 γにアクセスし、 鍵情報と共有メンバ一 Βに対応する暗号化鍵 Βを取得する （ステップ S 8 0 1 γ )。 共通鍵復号化部 1 8 γは、 受信者である共有メンバ一 Βの秘密鍵を用い て暗号化鍵 Βを復号化し、 共通鍵を得る （ステップ S 8 0 2 y ) c 共通鍵改竄検出情報作成部 1 9 γは共通鍵から共通鍵改竄検出情報を作 成する （ステップ S 8 0 3 γ )。 そして改竄検証部 2 0 γは、 取得した鍵情報と共通鍵改竄検出情報を比 較検証し鍵作成者の正当性を確認する （ステップ S 8 0 4 y )。 この場合、 2つの情報が一致することで改竄が行われていないことが検証される。 ステップ S 8 0 4 γで、 鍵作成者の正当性が確認されると、 共通鍵暗号 化部 1 6 7は共有メンバーとして追加する共有メンバー Cの公開鍵を用い て共通鍵を暗号化し、 暗号化鍵 Cを生成する （ステップ S 8 0 5 y )。 鍵暗号化部 1 2 γは生成された暗号化鍵 Cを情報保管装置 3 0 γへ転送 6δ する （ステップ S 8 0 6 γ )。 こう して、 情報保管装置 3 0 γには 3人の共有メンバーに対応する暗号 化鍵 A、 B、 Cが保管されることになり、 以後、 追加された共有メンバ一 Cは、 チームの暗号化情報に対する参照 ·変更等を行なえるようになる。 図 2 7に、 共有メンバー Cの追加前の暗号化情報の構成と、 追加後の構 成を示す。 ここでは、 暗号化情報として、 あらたな共有メンバーである共 有メンバー C用の暗号化鍵 Cがもとの暗号化情報に追加されていることを 示している。 次に、 共有メンバーを削除する際の暗号化複号化装置 1 0 γの動作を図 2 8に示す動作フローチャー トを参照して説明する。 ここでは、 共有メン バ一 A、 B、 Cが所属しているチームにおいて、 共有メンバ一 Bが共有メ ンバ一 Aを削除する場合を説明する。 暗号化復号化装置 1 0 Ίは、 共有メンバ一 Βの入力操作による共有メン バ一 Αを削除するための削除命令を取得する （ステップ S 1 0 1 γ )。 データ改竄検出情報作成部 2 2 γは、 共有メンバー Αの削除命令に対応 するデータ改竄検出情報を作成する （ステップ S 1 0 2 τ ) 0 次に、 暗号化複号化装置 1 0 γは、 共有メンバーの削除命令と、 削除命 令を出した本人を識別する識別情報となるデータ改竄検出情報の組からな る削除情報を情報保管装置 3 0 γに転送する （ステップ S 1 0 3 γ ) σ なお、 情報保管装置 3 0 は、 削除命令を出した本人を識別する機能を 66 . もち、 削除命令に応じた暗号化鍵を削除できるものとする。 また、 ここで 用いるデータ改竄検出情報として、 共有メンバー Aの削除命令に対する共 有メンバー Bのデジタル署名を用いてもよい。 また、 削除命令を出した本 人を識別する識別情報と して I D、 パスヮード等を用い情報保管装置 3 0 が、 情報保管装置 3 0 γに登録されている識別情報とを照合するように してもょレ、。
図 2 9に、 共有メンバー Αの削除前の暗号化情報の構成と、 削除後の構 成を示す。 ここでは、 暗号化情報として、 共有メンバ一 A用の暗号化鍵 A がもとの暗号化情報から削除されていることを示している。 次に本実施形態の暗号化復号化装置 1 0 γの動作を具体例をあげて詳細 に説明する。
まず第 3— 1の実施例として、 ユーザ Βが、 チーム 1 0 1 γ (ユーザ Α、 B、 Cの 3人が所属） で共有しているスケジュールの 1 9 9 8年の 1 0月 1 日の項目に用件 「セミナ一参加」 と 「 1 5 : 0 0」 を加える際の処理を 説明する。 なお本実施例では、 スケジュールに関する情報は暗号化情報と 暗号化されていない情報を含み
、 外部の情報保管装置 3 0 yに保管されているものとする。 また情報保管 装置 3 0 yは、 ユーザのアクセス権に応じて保管されている情報に対する アクセスを制限できるものとする。 また、 ユーザ Bが使用する暗号化復号 化装置 1 0 γは、 ユーザ Βによるデータの入力を受け付ける入力部 （図示 せず） と、 情報を表示する表示部 （図示せず） を備えているものとする。 まず、 ユーザ Βは暗号化複号化装置 1 0 Ίから情報保管装置 3 0 yにァ クセスし、 チーム 1 0 1 yの 1 9 9 8年 1 0月のスケジュールにアクセス できるか確認する。 アクセス可能である場合、 チーム 1 0 1 γの 1 9 9 8年 1 0月のスケジ ユールにアクセスする。 情報保管装置 3 0 γは、 チーム 1 0 1 yの 1 9 9 8年 1 0月のスケジュールを暗号化復号化装置 1 0 γに転送し、 暗号化復 号化装置 1 0 Vはその表示部にスケジュールを表示する。 なお、 この段階 ではスケジュールの情報はまだ暗号化されていないものとする。 ユーザ Βは、 暗号化複号化装置 1 0 γの入力部を用いて 1 9 9 8年の 1 0月 1 日の項目に 「セミナ一参加」 と 「 1 5 ： 0 0〜」 を入力する。 次に、 共通鍵暗号化部 1 6 γにおいて共通鍵を生成する。 本実施例では この共通鍵を c K e y 1 y と呼ぶことにする。 次に、 共通鍵暗号化部 1 6 yで、 ユーザ A、 ユーザ B、 ユーザ Cの公開 鍵を利用して、 例えば公開鍵暗号方式である R S A方式で暗号化する。 こ うして共通鍵暗号化部では、 3人のユーザに対応して 3つの暗号化鍵が生 成される。 本実施例ではこれらの暗号化鍵をそれぞれ、 e K e y l A y、 e K e y 1 B γ , e K e y 1 C y と呼ぶことにする。 次に、 共通鍵改竄検出情報作成部 1 7 γは、 共通鍵のメッセ一ジダイジ ヱス トである MD γを作成し、 さらにこの MD γにユーザ Βの秘密鍵を利 用してデジタル署名を行なう。 このデジタル署名を行なった MD yが鍵情 報である S i g n e d K e y l yである c データ暗号化部 2 1 γは、 スケジュールのデ一タパ一ッである 「セミナ 一参加」 を共通鍵 c K e y 1 γで暗号化を行ない、 暗号文 C r y p t D a 68 . t a 1 yを生成する。 次に、 データ改竄検出情報作成部 2 2 γは、 一例と してハッシュ関数で ある M D 5を利用して 「セミナー参加」 のメッセ一ジダイジェス ト M e s s a g e D 1 γ ¾生成する。
「セミナ一参加」 に適用した手順をスケジュールのデータパーツである 「 1 5 ： 0 0〜」 に対して行ない、 Γ 1 5 ： 0 0〜」 の暗号文 C r y p t D a t a 2 yとメッセ一ジダイジェス ト M e s s a g e D 2 /を ί導る。 そしてこれらの情報を暗号化復号化装置 1 0 γから情報保管装置 3 0 に転送するつ
なお、 このときの情報保管装置 3 0 γに記憶される情報の構成を図 3 0 に示す。 上記処理で作成されたスケジュールを区別する情報、 ユーザ I D と暗号化鍵、 鍵情報、 暗号文とデータ改竄検出情報および関連情報が記憶 される。 次に第 3— 2の実施例として、 第 3— 1 の実施例からさらに、 第 3— 1 の実施例で作成された暗号化情報にユーザ Αが、 チーム 1 0 1 (ユーザ A、 B、 Cの 3人が所属） で共有しているスケジュールの 1 9 9 8年の 1 0月 2日の項目に用件 「会議」 と 「 1 7 ： 0 0〜」 を加える際の処理を説 明する。 まず、 ユーザ Aは暗号化複号化装置 1 0 γから情報保管装置 3 0 に了 クセスし、 チーム 1 0 1 γの 1 9 9 8年 1 0月のスケジュールにアクセス できるか確認する。 69
アクセス可能である場合、 チーム 1 0 1の 1 9 98年 1 0月のスケジュ —ルにアクセスする。 情報保管装置 3 0 T は、 暗号化鍵 e K e y 1 A γと 鍵情報 S i g n e d K e y l 7を暗号化復号化装置 1 0 Ίに転送する。 ユーザ Αは、 暗号化復号化装置 1 0 Ίの入力部を用いて 1 9 98年の 1 0月 2日の用件項目に 「会議」 と 「 1 7 : 0 0〜」 を入力する。 次に、 共通鍵復号化部 1 8 γは、 ユーザ Αの秘密鍵を用いて暗号化鍵 e K e y 1 Α γを復号化し共通鍵 c K e y 1 γを生成する。 次に、 共通鍵改竄検出情報作成部 1 9 γは、 共通鍵 c K e y l yのメ ッ セ一ジダイジェス ト k e y D 1 ' γを作成する。 次に、 改竄検証部 20 γは、 鍵情報の S i g n e d K e y l yをュ一ザ Bの公開鍵を利用して復号化し、 暗号化前の共通鍵のメッセージダイジ ス ト k e y D l yを得る。 そして、 k e y D l yと k e y D l ' γを比較 する。 k e y D l y と k e y D l ' yが等しければ、 チーム 1 0 1 γに所 属するユーザ Βによって作成された共通鍵を改竄されることなく取得でき たことがわかる。 こう して共通鍵の正当性が確認できる。 ここで、 ュ一ザ Βが共通鍵を作成することが正当であるかどう力、 すなわち、 共通鍵作成 者自身の正当性確認は、 共通鍵作成者正当性確認用情報として取得する必 要がある。 この場合の共通鍵作成者正当性確認用情報の取得方法の一例と しては、 共通鍵作成者がユーザ Βであることを暗号化複号化装置 1 Ο γの 表示部にダイアログボックスとして表示し、 ュ一ザに確認してもらう方法 をとつてもよい， または、 ネッ トワークを介して情報保管装置 30 から 70 関連情報として取得してもよい。 次に、データ暗号化部 2 1 は、スケジュールのデータパーツである「会 議」 を共通鍵 c K e y 1 γで暗号化を行ない、 暗号文 C r y p t D a t a 3 yを生成する。 次に、 データ改竄検出情報作成部 2 2 τ は、 一例としてハッシュ関数で ある MD 5を利用して 「会議」 のメッセージダイジェス ト M e s s a g e D 3 を生成する。
「会議」 に適用した手順をスケジュールのデータパーツである 「 1 7 : 0 0〜
」 に対して行ない、 「 1 7 ： 0 0〜」 の暗号文 C r y p t D a t a 4 y と メッセ一ジダイジェスト M e s s a g e D 4 yを得る。 そしてこれらの情報を暗号化復号化装置 1 0 Ίから情報保管装置 3 0 7 に転送する。
なお、 このときの情報保管装置 3 0 γに記憶される情報の構成を図 3 1 に示す。 上記処理で暗号文とデータ改竄検出情報が追加されているところ を示している。 次に第 3— 3の実施例として、 第 3— 1、 第 3 — 2の実施例で作成され 情報保管装置 3 0 yに保管されているチーム Ι Ο Ι γの 1 9 9 8年 1 0月 のスケジュールをユーザ Cが参照する場合の処理を説明する。 まず、 ユーザ Cは暗号化複号化装置 1 0 Ίから情報保管装置 3 0 yにァ 71 . クセスし、 チ一ム 1 0 1 γの 1 9 9 8年 1 0月のスケジュールにアクセス できるか確認する。 アクセス可能である場合、 チ一ム 1 0 1 γの 1 9 9 8年 1 0月のスケジ ユールにアクセスする。 情報保管装置 3 0 γは、 チ一ム 1 0 1 γの 1 9 9 8年 1 0月のスケジュールと暗号化鍵 e K e y 1 C γ と鍵情報 S i g n e d Κ e y 1 7を暗号化復号化装置に転送する。 共通鍵複号化部 1 8 yは、 ユーザ Cの秘密鍵を用いて暗号化鍵 e K e y 1 C yを復号化し共通鍵 c K e y 1 γを得る。 次に、 共通鍵改竄検出情報作成部 1 9 γで、 共通鍵 c K e y 1 γのメ ッ セージダイジェス ト c K e y D ' vを作成する。 改竄検証部 2 0 γでは、 S i g n e d K e y l yをユーザ Bの公開鍵を 用いて複号化し、 暗号化前の共通鍵のメッセージダイジェス ト c K e y D γを得る。 そして、 このメ ッセージダイジエス 卜 c K e y D y と先のメッ セージダイジェス ト c K e y D ' γを比較する。 この 2つのメ ッセ一ジダ ィジエス トが等しければチーム 1 0 1 γに所属するユーザ Βによって作成 された共通鍵 c K e y 1 γを改竄されることなく取得できたことが検証で きる。 すなわち、 取得した共通鍵の正当性を確認することができる。 また、 ここで共通鍵作成者自身の正当性確認を行なう必要があるが、 第 3 — 2の 実施例で説明したとう りである。 次に、 データ複号化部 2 3 γは、 暗号文 C r y p t D a t a 1 7を共通 鍵複号化部 1 8 γより取得した共通鍵 c K e y 1 7を用いて複号化を行な 72 う。 ここで平文 「セミナー参加」 が得られる。 次に、 データ改竄検出情報作成部 24 γで、 ハッシュ関数の 1つである MD 5を用いて平文のメッセージダイジエス 卜 M e s s a g e D l ' γを 生成する。 情報保管装置 3 0 γより転送されてきたメッセージダイジエス ト Me s s a g e D 1 7とデータ改竄検出情報作成部 2 4 γで生成されたメッセ一 ジダイジェス ト M e s s a g e D 1 ' γを比較する。 これら 2つのメッセ ージダイジヱス トが等しければチーム 1 0 1 yに所属する者によって作成 されたデータパーツを改竄されることなく取得できたことがわかる。 同様の手順を繰り返すことで暗号文 C r y p t D a t a 2 y-C r i p t D a t a 4 7に対して行なう と、 「 1 5 ： 0 0〜」、 「会議」、 「 1 7 : 0 0〜」 を得ることができる。 複号化後のスケジュールの表示例を図 3 2に 示す。 図に示すようにュ一ザ Bが入力したデータパーツ 「セミナ一参加」、 「 1 5 ： 0 0〜」 とユーザ Aが入力したデ一タパ一ッ 「会議」、 「1 7 : 0 0〜」 を同じチームに所属するュ一ザ Cは見ることができる。 以上のように、 1つのチームに所属する共有メンバーは、 暗号化情報に 対するデータパーツの追加や変更、 他共有メンバーのデータパーツの参照 等、 自由に行なえるが、 共有メンバー以外の者に対して秘匿性を保つこと ができる。 また一例として、 l e s s a g e D l y、 ―.、 Me s s a g e D 4 yの 各サイズを 1 6バイ ト、 鍵情報のサイズを 2 3 0 0バイ ト （下限がある） 73 . であるとすると、 本実施例では
1 6 x 4 + 2 3 0 0 = 2 3 6 4ノくィ ト
がオーバ一へッ ドとなる。
従来の方式で 4つの暗号文のそれぞれにデジタル署名を付ける場合では
2 3 0 0 x 4 = 9 2 0 0ノくィ ト
のオーバーへッドとなり、 本発明の方式が従来方式より情報量を抑えるこ とができている。 なお、 第 3の実施形態の発明は、 インターネッ トの他、 LANやダイァ ルアップによるネッ トワークを利用してもよレ、。
また、 本発明の暗号化装置、 複号化装置、 及び方法を実現するためのプ 口グラムをコンピュータ読み取り可能な記録媒体に記録して、 この記録媒 体に記録されたプログラムをコンピュータシステムに読み込ませ、 実行す ることにより暗号化
、 復号化の処理を行ってもよい。
すなわち、 暗号化プログラムを記録したコンピュータ読み取り可能な記 録媒体において、 暗号化プログラムは、 共通鍵暗号方式を利用して暗号化 に用いる共通鍵を取得または生成する機能と、 公開鍵暗号方式を利用して 前記共通鍵を暗号化し暗号化鍵とする機能と、 前記共通鍵より鍵情報を作 成する機能と、 平文を共通鍵暗号方式を利用して暗号化し暗号文とする機 能と、 前記平文より第 1データ改竄検出情報を作成する機能をコンビユー タに実現させる。
また、 復号化プログラムを記録したコンピュータ読み取り可能な記録媒 体において、 復号化プログラムは、 公開鍵暗号方式を利用して前記暗号化 鍵を複号化する機能と、 前記暗号化鍵を復号化した共通鍵より共通鍵改竄 検出情報を作成する機能と、 前記鍵情報と前記共通鍵改竄検出情報とから 74 . 改竄検証する機能と、 前記暗号文を共通鍵暗号方式で復号化する機能と、 前記暗号文を復号化した平文より第 2データ改竄検出情報を作成する機能 と、 前記第 1データ改竄検出情報と前記第 2データ改竄検出情報とから改 竄検証する機能をコンピュータに実現させる。 以上、 詳細に説明したように、 第 3の実施形態の発明によれば平文毎に 改竄検出情報を作成することはせず、 各平文を暗号化する共通鍵に対して 改竄検出情報となる鍵情報を作成し、 改竄検出と共通鍵作成者の本人確認 を可能としたので、 情報を暗号化した暗号化情報のオーバ一へッ ドを减少 させることができる。 したがって、 暗号化情報の転送時におけるネッ トヮ —クにかかる負荷と暗号化情報を保管する際に要する記憶装置の容量を减 少させることができる。 また、 各平文に第 1データ改竄検出情報を付加し たので、 個々の平文毎に改竄検出が可能である。 また、 利用者毎に暗号化 鍵を作成することで複数の利用者間で暗号化情報を共有できる。 第 4 一 1 〜 4 一 4の実施形態の発明は、 複数のユーザ （メ ンバ） から構 成される企業の部や課といったチームを階層化するためのチームデータリ ス トを作成， 管理， 保管してゆく とともに、 ユーザに提供される各種の情 報や様々な機能をユーザ間で安全に共有するためのチームデータリス ト処 理システムに関するものである。 さらに詳細には、 チームデータリストの 保管に係わる処理を担うチームデータリス ト保管装置と、 チームデータリ スト保管装置上から取得したチームデータリス トを対象に様々な管理を行 うチームデータリス ト管理装置を備えたシステムに関するものである。 第 4 一 1 〜4 一 4の実施形態の発明に関し、 従来以下説明する技術が知 られている。 75 - ユーザに提供される各種の機能や情報といった様々な資源を複数のユー ザ間で共有するためには、これら資源にアクセスを要求しているユーザが、 本当に資源へアクセスする権利を有しているのか否かを検証する機能を用 意しておく必要がある。 かかる検証を行うために、 従来は、 資源に対する 正当なアクセス権限を付与されたュ一ザを予め定義したアクセスコント口 —ルリス ト （以下、 「A C L」 と略記する） と呼ばれるリス トを利用して いる。 なお、 ここで言う A C Lは、 上述したチームデ一タリス トに含まれ る種々の情報のうち、 共有資源に対するアクセスを制御するための情報だ けが含まれたリス 卜の一例である。 図 5 1は、 A C Lを利用して複数のユーザ間で情報共有を行う従来のシ ステムの概要を示したものである。 同図に示されるシステムでは、 イント ラネッ ト 1 ό， ィンタ一ネッ ト 2 δがそれぞれファイアウォール 3 6， 4 δを介してサーバ 5 6に接続されており、 イントラネッ ト 1 δ内部の者ば かりでなく、 イントラネッ ト外の共有メンバ 6 δがィンタ一ネッ ト 2 δを 介して互いに情報を共有している。 周知のように、 イントラネッ ト 1は企 業内に整備されたネッ 卜ワークなどの閉じたネッ トワークであり、 その一 方で、 インターネッ ト 2 δは世界中にまたがるパブリ ックなネッ トワーク である。 また、 ファイアウォール 3 0， 4 δは悪意を持った侵入者などがイント ラネッ ト 1 δへ不正にアクセスすることを防止するためのコンピュータで ある。 サーバ 5 όは各種の資源が蓄積されている端末 （コンピュータ） で あって、 共有情報が格納されたデータべ一ス 7と、 特定の情報ないし機能 にアクセスしても良いグループ及びそれに属するメンバのメンバリス トを 保持した A C L 8 δを備えている。 このサーバ 5 δは、 データベース 7に 76 蓄積されている共有情報を管理するデータ保管機能のほか、 クライアント に相当する通信相手が予め許可されている者か否かを検証するユーザ認証 機能， A C L 8 δに基づいて共有情報に対するアクセスの可否を検証する アクセス制御機能， A C L 8 δに基づいて特定のグループに属するメンバ だけが特定の共有情報へアクセスすることを可能ならしめるグループ管理 機能を備えている。 図 5 1のシステムでは、 共有メンバ 6 6ゃィントラネッ ト 1 δ内部のュ 一ザからデータベース 7 δに対するアクセス要求があると、 サーバ 5 δは その都度 A C L 8 δを参照してユーザ認証を行い、 当該ユーザがメンバと して A C L 8 6に定義されていればアクセスを許可し、 メンバとして定義 されていなければアクセスを拒否する。 また、 当該ユーザに対してァクセ スが許可されている場合、 サーバ 5 Sほ A C L 8 δを参照して当該メンバ が特定のグループに含まれるかどうかを確認するとともに、 当該メンバが アクセス要求のある共有情報に関してアクセスを許されているかどうか調 ベるようにしている。 ところで、 複数のユーザ間で資源を共有する場合にはサーバ側の管理者 を共有メンバに含めるのが好ましくない場合もある。 例えば、 ある企業の 情報システム部に所属するシステム管理者は、 人事部内だけで共有すべき 企業の人事情報にアクセス不可能であることが必要と考えられる。 ところ が、 上述した図 5 1のようなシステムでは、 サーバ 5 δの管理者に対して A C L 8 6の設定や管理を行う権限を許与してしまっている。 そのため、 サーバ管理者 5 δが A C L 8 δに対して不正なアクセスを行うことが可能 であり、 意図的に A C L 8 όの設定内容が改竄されるのを防止することが できない欠点がある。 これに加えて、 サーバ管理者以外にも、 サーバ S V 77
δ へ不正に侵入する者 （いわゆるクラッカ） によって A C L 8 δが不正に 改竄されてしまうおそれもある。 このほか、 企業内部で情報を共有してゆく利用形態などへの適用を考え た場合
、そうした形態にうまく適合したシステムを構築してゆくことが望ましい。 すなわち、 ある程度以上の規模の企業では組織がビラミッド状に形成され た階層関係になっており、 例えば、 人事部の配下には人事一課や人事二課 が設置されていることなどはごく一般的であると言える。 また、 開発部門 などでは商品の開発工程などに合わせて例えば開発部長が新たに課を作つ たり、 幾つかの課を統合したり
、 あるいは、 ある特定の課を廃止したりする権限が与えられている場合も 考えられる。 また、 それぞれの課が業務別にいくつかのグループに分かれ ていることもある。 そう した組織にあっては、 開発部長が各課やそれぞれの課に属する全て のグループの構成員を管理することは非常な負担である。 そこで、 こうし た管理負担を分散するために、 開発部長を補佐する者を何人か割り当てる ようにしてこれらの者に管理業務の一部又は全部を代行させることなどが 行われている。 さらには、 開発部長には課の作成， 統廃合等の業務を行う 権限だけを与えておき、 課内部の管理や情報共有自体は課長やその下のグ ループリーダ等に一任するといつた形態が採られている。 しかるに、 上述 した従来のシステムではいま説明したような企業の組織形態に適合した柔 軟な管理や情報共有は何ら考慮されていないという問題がある。 本発明は上記の点に鑑みてなされたものであり、 その目的は、 サーバの 78 管理者といった特権者も含め、 企業の組織単位等に相当するチームの外に いる者，クラッカ等がチームデータリス トに不正を行うことを防止しつつ、 チームの階層化および各種の情報や機能の実現するためのチームデータリ ス ト処理システムを提供することにある。 さらに詳しくは、 各チームに所 属しているメンバから特に選ばれた者だけが、 チームの配下にサブチーム を作成したり、 サブチームの作成権限を特定の複数人に割り当てたり、 サ ブチームの作成権限者が選定した特定人にサブチーム内の管理を行わせた りすることが可能なチームデータリスト処理システムを提供することにあ る。 以下、図面を参照して第 4一 1〜4— 4の実施形態について説明するが、 まず初めに本発明におけるチームデータリス トについて説明する。 本発明 におけるチームデータリス トは、 チームに関する情報を定義したリス トの 総称であって、 上述した A C Lのような機密性の高い管理が要求される用 途に適用される 「メンバの集合」 を定義するためのものである。 上述した 通り、 従来のシステムでは、 チームのメンバではない端末管理者， ネッ ト ワーク管理者， サーバ管理者などがチームに関する情報を変更することが できる。 一方、 本発明におけるチームデータリス トでは、 チームに関する 情報を複数のリス ト （後述するようなオーソリティ リス ト， オーソリティ デ一タやメンバリス ト， チームマスタリス ト， アプリケーションリス ト） に分割して管理することで、 チームの階層化やチームマスタ自身の変更と いったチーム管理をチーム内のメンバだけで行えるようにしている。 以下に詳述する実施形態では、 第一に、 チームの配下にサブチームを作 成できるようにして、 会社組織等における階層関係を模擬して情報共有を 行ってゆく仕組みを実現している。 第二には、 特に選定された複数の人間 79 に対してサブチームの作成権限を授与できるような仕組みを実現しており、 それによつて一人の管理者に負荷が集中しないようにして管理負担の分散 を図っている。 第三には、 サブチーム内部の管理については、 サブチーム 作成権限者がサブチーム内から選んだ特定の者に行わせる仕組みを実現し ている。 そうすることによって、 チームの管理者がサブチーム内部の管理 や情報共有に関与しなく とも済むようにしている。
〔第 4一 1実施形態〕
本実施形態では、 階層化されたチームに合わせて、 チームデータリス ト にアクセスできる者をその権限の内容に応じてメンバ，サブォーソリティ， チームマスタの 3種類に分類しており、 この順番でその者に付与される権 限が拡大してゆく
。 チームマスタは或るチームの管理者であって、 当該チームの配下の組織 たるサブチームの作成といった管理権限を有する者である。 一方、 サブォ ーソリティはチームマスタによって指名された者であって、 チ一ムマスタ と同様にサブチームの作成といった管理権限を持つ者であるが、 他の者を サブォーソリティとして指名することは許されていない。 サブォーソリテ ィは複数人いる場合もあれば一人もいない場合もある。 他方、 サブォ一ソ リティ及びチームマスタ以外の一般のメンバは情報や機能を共有する者で あって、 サブチームの作成権限などの特権はいつさい与えられていない。 なお、 サブォ一ソリティやチームマスタは特別な権限が与えられてはいる 力 チーム内のメンバであることに変わりはなく、 その意味でサブォ一ソ リティやチームマスタをメンバと呼ぶこともある。 なお、 以下の説明及び 図面ではチームマスタを 「Τ Μ δ」 と略記し、 サブオーソリティを 「 s u b A U 5」 と略記することがある。 80 以下、 チームデータリス ト管理装置及びチームデータリス ト保管装置の 2つの装置を備えたシステムについて本実施形態を説明してゆく。 図 3 7 は、 チームデータリスト管理装置及びチームデータリス ト保管装置を具備 した本実施形態のシステム全体の構成を示したプロック図である。 同図に おいて、 チームデータリス ト管理装置 3 0 6， チームデータリスト保管装 置 3 1 δは以下に詳述するチームデータリス ト管理機能， チームデータリ スト保管機能をそれぞれ備えており、 互いに通信機能を利用してデータを 授受している。 チームデータリス ト管理装置 3 0 δ， チームデータリス ト 保管装置 3 1 δは何れもワークステーショ ンなどの一般的なコンピュータ で実現することが可能であり、 これらコンピュータの主記憶上にはそれぞ れチ一ムデータリス ト管理機能， チームデータリス ト保管機能を実現する ためのプログラム （チームデータリス ト管理プログラム， チームデータリ ス ト保管プログラム） が記憶される。 これらのプログラムはフロッピ一ディスク， I C (集積回路） カード， 光磁気ディスク， C D— R O M (コンパク トディスク一読み取り専用メモ リ） 等の可搬性のある記憶媒体や、 コンピュータに内蔵されるハードディ スクなどの大容量の記憶媒体といったコンピュータ読み取り可能な記憶媒 体にその一部又は全部が記憶されている。 すなわち、 当該プログラムは以 下に詳述する機能の一部を実現するためのものであっても良く、 さらには コンピュータにすでに記録されているプログラムとの組み合わせでこれら 機能を実現できるものであっても良い。 そして
、 チームデータリス ト管理装置やチームデータリス ト保管装置を作動させ るにあたって、 これらのプログラムがコンピュータ上の C P U (中央処理 装置） の指示の下に予め記憶媒体から主記憶上に転送される。 その後、 C P Uは主記憶上に転送されたプログラムを実行し、 それによつて装置各部 81 · を制御して、 以下に詳述する様々な処理を実現している。 なお、 ここで言う 「コンピュータ」 には O S (オペレーティングシステ ム） や周辺機器等のハードウェアが含まれている。 また、 コンピュータ読 み取り可能な記憶媒体としてはいま述べたようなプログラムを静的に記憶 するものに限られるものではなく、 専用線や電話回線などの通信回線を通 じて短時間だけ動的にプログラムを保持するもの， 即ち、 インターネッ ト 等のネットワークでプログラムやデータを保持， 転送， 中継するサーバ， ルータ， ゲ一卜ウェイといったコンピュータ機器に内蔵された主記憶ゃキ ャッシュメモリ、 サーバ， クライアン トと して機能するコンピュータ内部 の揮発性メモリなどのように、 一定時間プログラムを保持可能なものをす ベて包含している。 さて、 図 3 7に示すチームデータリス ト保管装置 3 1 δにはハ一ドディ スク等のデータベースを構築可能な記憶装置 3 2 δが接続されている。 こ の記憶装置 3 2 δは、 複数のメンバで構成されるチーム毎にォ一ソリティ データ 3 3 δ とォ一ソリティ リス ト 3 4 δからなるチームデータリス トの 組を記憶している。 同図では説明の都合からオーソリティデータ 3 3 δ及 びオーソリティリス ト 3 4 δの組を一つだけ示しているが、 実際にはチー ムの数だけこれらの組が存在している。 ここで、 図 3 8 Α， Βはォ一ソリ ティデータ 3 3 δ， オーソリティ リスト 3 4 δの詳細な構造を示したもの である。 また、 図 3 8 C, 3 8 Dはこれ以後に掲げる図面中において、 ォ —ソリティデータ 3 3 δ， オーソリティ リス ト 3 4 δの記憶内容を簡略化 して示すための表記法をそれぞれ示したものである。 なお、 以下の説明及 び図面ではオーソリティデータを 「AUD 0」 と略記し、 オーソリティリ ス トを 「AU L 0」 と略記することがある。 82
ォ一ソリティデータ 3 3 δは或るチームとその配下のサブチームとの関 係を表すデータであって、 サブチームとの関係において上位にある当該チ —ムを親チームと呼ぶ。 図 3 8 Αに示すように記号 " A U D δ " がォーソ リティデータであることを示しており、このォーソリティデータ 3 3 δは、 自身のチームに付与された識別子たるチーム I D 3 3 a δ， このチームの 親チームに付与されたチーム I Dである親チーム I D 3 3 b δ， 親チーム の誰がこのチームを作成したかを意味するチーム作成者 3 3 c 0， このチ —ムに属するメンバの誰に対してチームマスタ権限を与えたかを示すチ一 ムマスタ 3 3 d δ， チーム作成者 3 3 c όのデジタル署名がなされるデジ タル署名 3 3 e Sを含んでいる。 また、 図 3 8 Cにおいて、 このォーソリ ティデータはチーム 1 0 1 δのサブチームであるチーム 1 0 2 δに関する ものであることが分かる。 これに加えて、 デジタル署名からこのォ一ソリ ティデータのチーム作成者がメンバ Β 6であることが分かるほか、 チーム マスタがメンバ X δであることが分かる。 一方、 オーソリティ リス 卜 3 4 0は各チームにおける複数の管理者を登 録したリス 卜であって、 当該チームのチームマスタやサブォーソリティに 関するデータが含まれている。 図 3 8 Βに示すように記号 " A U L δ " が オーソリティ リス トを意味しており、 このォーソリティ リス ト 3 4 δはこ のチームに関するチーム I D 3 4 a δ， チームマスタ 3 4 b δ， サブォー ソリティ 3 4 c δ (同図の場合は二人）， チ一ムマスタ 3 4 b δのデジタ ル署名であるデジタル署名 3 4 d δを含んでいる。 そして、 図 3 8 Dによ れば、 チームマスタがメンバ X δであってそのデジタル署名がなされてい るほか、 サブォ一ソリティがメンバ C δ及びメンバ D δであることが分か る。 なお、 図 3 8 Dではチーム I Dの表記自体は省略されている。 以上の 83 ように、 本実施形態によるチームデータリ ス トは、 親チーム及びサブチー ムの関係を示すリス トである A U D S と、 サブチーム管理に関わるリス ト である A U L δに分割された構造となっている。 なお、 オーソリティデータ 3 3 δやォ一ソリティリス ト 3 4 δには、 図 3 8 Α , 3 8 Β , 3 8 C , 3 8 Dに示した以外にも、 これらデータやリス トの作成時間を示すタイムスタンプ， デジタル署名 3 3 e δやデジタル署 名 3 4 d δを作成するのに用いられるデジタル署名アルゴリズム， ォーソ リティデータ 3 3 δやォ一ソリティ リス ト 3 4 δ 自身の有効期限， ォ一ソ リティデータ 3 3 δやォ一ソリティ リス ト 3 4 δ 自身の識別番号に関する データなどを含んでいる。 また、 メンバ， サブオーソリティ， チ一ムマス タの各個人を識別するための I D (識別子） としては、 名前， メールアド レス， 組織上の名称， 個人のシリアルナンパ， デジタル証明書等、 種々の ものを用いることが可能である。 次に、 図 3 9は階層化されたチームの概念図についてその一例を示した ものである。 同図に示されるように、 チームの階層はコンピュータのファ ィルシステムのように木構造になっており、 図中の楕円形がチームを表現 するとともに、 親チームとそのサブチームが直線で互いに結ばれている。 各チームには複数のサブチームを登録することができ、 例えば人事部のチ ームの配下に人事一課， 人事二課などのサブチームを登録することが可能 になっている。 また、 頂点に存在するチーム 1 ◦ 1 0は木構造の根に相当 しているため、 ファイルシステム上のル一トディ レク トリになぞらえて本 実施形態では 「ル一ト （R o o t δ )」 ないしル一トチームと呼んでいる。 さらに、 チーム 1 0 2 δ及びチーム 1 0 3 δは何れもチーム 1 0 1 δのサ ブチームであって、 木の上では同じ階層に属するチームである。 一方、 チ 84
—ム 1 0 4 δはチーム 1 0 3 δのサブチームである。 一方、 図 4 0は図 3 9に示したチーム階層に対応させて各チームのォ一 ソリティリストゃォーソリティデータについて具体的な値を記入したもの である。 なお、 同図ではオーソリティリス ト及びオーソリティデータの他 に、 互いに情報や機能を共有する共有メンバの一覧を示したメンバリス ト
(図中の 「M L δ」） が各チームに含まれている例を示してある。 つまり、 この図においては、 チームデータリストがオーソリティ リス ト， ォ一ソリ ティデータ， メンバリス トの 3種類のリス トで構成される。 各メンバリス ト 1 0 1 m 6〜 1 0 4 m 0にはメンバリストの作成者のデジタル署名とメ ンバの一覧が図示されているが、 これ以外にも、 チームの利用目的に合致 した様々なチームの管理情報が含まれている。 すなわち、 各メンバの識別 情報， 各メンバに付与された公開鍵方式における公開鍵 （即ち、 所定長の ビッ ト列） とこの公開鍵に対応する保有者の識別子 （以下、 「公開鍵 I D」 という）， チーム I D， メ ンバリス トの作成時間を示すタイムスタンプ， チーム内のメンバが利用できる機能 （例えば、 アプリケーショ ン） に関す る情報などが含まれている。 このほか、 それぞれのメンバリス トには各メ ンバに関する情報として、 e _ m a i 1 (電子メール） ア ドレスゃメ 自身の住所といった情報も含まれており、 これらを用いることで各メ に関する情報リソースの管理も同時に行うことができる。 同図に示す構成によれば、 ォーソリティデータに記述された親チーム I Dを迪つてゆくことで、 何れのサブチームからもル一トたるチーム 1 0 1 δに到達することができる。 このほか、 各チームでは複数の管理者がサブ チームを作成可能である。 例えばチーム 1 0 1 δではチームマスタ Α及び サブオーソリティ B , Cがサブチームの作成権限を有しており、 ォ一ソリ 85 ティデータ 1 0 2 d S， 1 0 3 d δのデジタル署名から分かるように、 サ ブチームたるチーム 1 0 2 δ， 1 0 3 δはそれぞれチーム 1 0 1 0のサブ オーソリティ B， Cが作成している。 あるサブチームのォーソリティデータは当該サブチームの親チームに登 録された管理者が作成することになつている。 また、 当該サブチーム内の 誰もが親チームの管理者の指示によってこのサブチームのチームマスタに なることができる。 例えばチーム 1 0 4 δでは、 オーソリティデータ 1 0 4 d 6 のデジタル署名がメンバ Vであるから、 親であるチーム 1 ◦ 3 δ の 管理者の一人であるサブォ一ソリティ Vがォ一ソリティデータ 1 0 4 d δ を作成しており、 チーム 1 0 4 δのチームマスタとしてメンバ Lを指名し ている。 一方、 ォ一ソリティ リス トは各チームのチームマスタが作成してデジタ ル署名することになつている。 例えば、 チーム 1 0 3 0のォーソリティリ ス ト 1 0 3 u δはチームマスタたるメンバ X όが作成したものであって、 そこにはメンバ X δのデジタル署名がなされている。 そのため、 ォ一ソリ ティリス ト 1 0 3 ια δ中のサブォ一ソリティに関するデータはメンバ Xの みが管理できることになり、親チームたるチーム 1 0 1 δの管理者（即ち、 チームマスタ Αやサブオーソリティ B， C ) の干渉を受けることはない。 換言するならば、 オーソリティ リス トのデジタル署名者をチームの作成者 (即ち、 親チームのチームマスタやサブオーソリティ） にしてしまうと、 例えば人事部長が人事課長に課内部の管理を任せることができなくなって 自分で管理してゆかねばならなくなる。 同様にして、 メ ンバリス トのデジ タル署名についても各チームのチームマスタが行うことから、 各チーム内 の共有メンバに関する管理についても親チームの干渉を受けずに済むこと 86 になる。 例えばチーム 1 0 3 δ のメ ンバリス 卜 1 0 3 m 5はチームマスタ Xがデジタル署名しているため、 親チームの管理者が管理することはでき ない。 ただし、 サブチームを最初に作成したときの初期状態や、 サブチー ムのチームマスタを親チームのチームマスタやサブォ一ソリティが変更し た場合には、 オーソ リティ リス トのデジタル署名は、 該サブチームを作成 した親チームのチームマスタ又はサブォ一ソリティのデジタル署名となつ ている。 以上の点をまとめると、 本実施形態ではォ一ソリティデータとォ一ソリ ティ リ ス トを分離する構成としており、 親チームはサブチームのォーソリ ティデータ A U D δを参照することができる一方、 親チームの管理者がォ —ソリティ リス トやメンバリス トを改竄できないようにすることで、 サブ チーム内部の管理に親チームは関与しないようにしている。これによつて、 各チームのチームマスタは、 自分でサブォ一ソリティを選択できるほか、 チーム内の情報共有のメンバ管理も行うことができる。 次に、 図 3 7のチームデータリ ス ト保管装置 3 1 όにおいて、 権限確認 機能 3 5 δはクライアン ト C L S側からォーソリティデータ 3 3 6ゃォー ソリティ リス ト 3 4 δに対する参照， 変更， 削除の各要求があつたときに、 要求者を識別してこれらの要求を許可するのか拒否するのかを判断する。 この判断にあたっては、 要求対象となっているチームのチームマスタ， サ ブォ一ソリティや当該チームの親チームやサブチームとの間の関係のほか、 チームに所属するメンバ等の権限と要求者本人に与えられている権限など を照らし合わせている。 つまり、 要求内容によって判断手順の詳細が異な るためその詳細については後述する動作説明に譲る。 次に、 リ ス ト保管機 能 3 6 δは権限確認機能 3 5 όがオーソリティデータ 3 3 6ゃォーソリテ 87 - イ リス ト 3 4 δを使用するにあたって、 これらのリス トを記憶装置 3 2 δ から取得し， 記憶装置 3 2 όから削除し， あるいは記憶装置 3 2 δへ保存 する処理を司っている。 以下の説明では、 権限確認機能 3 5 δがォ一ソリ ティデータ 3 3 δやォーソリティ リス ト 3 4 δにアクセスする場合には必 ずリス ト保管機能 3 6 δが介在することを前提としているが、 煩雑になる ため一々説明しない。 次に、 チームデータリ ス 卜管理装置 3 0 δにおいて、 リス ト正当性確認 機能 3 7 δはルートチームに至るまで親チームのォーソリティ リ ス ト及び ォ一ソリティデータを順次迪つてゆき、 最終的にチーム 1 0 1 0のチーム マスタ Αのデジタル署名を確認してォ一ソリティ リス ト及びォ一ソリティ データの正当性を検証している。 なお、 ここで言う正当性とは改竄や越権 行為などが無く正当な手順を経てチーム階層の管理が行われていることを 意味している。 次に、 A U D · A U L変更機能 3 8 δは、 リ ス 卜正当性確 認機能 3 7 όが取得したオーソリティデータ 3 3 δゃォーソリティ リス ト 3 4 δに対してメ ンバや管理者の追加， 削除， 置換などの変更を加えるほ か、 サブチーム作成時などではォ一ソリティデータ 3 3 ό及びォーソリテ イリス ト 3 4 δを新たに作成することもある。 次いで、 デジタル署名機能 3 9 δは A U D · A U L変更機能 3 8 6によって処理がなされたォ一ソリ ティデ一タ 3 3 δやォーソリティ リス ト 3 4 δに対し、 変更者本人しか知 り得ない秘密鍵ないしデジタル署名鍵を用いた暗号とハッシュ関数とを併 用してこれらリス トの作成者ないしは変更者 （即ち、 チームマスタ又はサ ブオーソリティ） のデジタル署名を付加する。 次に、 公開鍵管理機能 4 0 δは、 チームデータリス ト管理装置 3 0 δに 接続された公開鍵データベース 4 1 δにアクセスして、 公開鍵と当該公開 88 鍵に対応する公開鍵 I Dを取得する。 ちなみに、 実際の形態において、 公 開鍵データベース 4 1 δはチームデータリス 卜管理装置 3 0 δに直接的に 接続された口一カルな形態のみならず、 インタ一ネッ ト等のネッ トワーク 上に設置されたサーバ （例えば、 認証局） に存在している形態も当然に考 えられる。 こうした形態によれば、 公開鍵管理機能 4 0 δは認証局上に登 録されたホームページを介して公開鍵データべ一ス 4 1 δにアクセスし、 そこから上述した公開鍵及び公開鍵 I Dをファイルの形式で取得すること も可能となる。 次に、 上記構成によるチームデータリス ト管理装置 3 0 6およびチーム データリス ト保管装置 3 1 6を有するシステムの動作についてクライアン ト C L δからサーバ S V 6に対して為される要求内容毎に説明してゆく。
〔サブチームの作成〕
図 4 1はサブチームを作成するための処理手順を示している。 ここでは 図 4 0に示したチーム 1 0 1 δ のサブォ一ソリティであるメンバ Cが、 チ
—ム 1 0 1 δの配下にチームマスタをメンバ Xとしたサブチーム 1 0 3 δ を作成するものとする。 これは、 人事部長の代行として部長代理が人事部 の下に課を新設する業務を遂行する場合などに相当する。 ここで、 チーム データリス ト保管装置 3 1 δでは正当な手順に従って作成されたチーム 1 0 1 δに関するチームデータリス トが予め記憶装置 3 2 6上に格納されて おり、 ルートチーム 1 0 1 δのチームマスタ Αによる管理体系でサブチ一 ムの作成が行われる。 なお、 図 4 0に示したように、 チーム 1 0 1 δには 親チームは存在しないのでォーソリティデータ 1 0 1 d δの親チーム I D には固定値 「R o o t 0」 が設定されているほか、 チームマスタはメンバ Aであるためォ一ソリテイデ一タ 1 0 1 d δ及びォーソリティ リス ト 1 0 89
1 u δには何れもメンバ Aのデジタル署名がされている。 もっとも、 ル一 トチームには仮想的に 「R o o t 0」 という親チームがあると見なすこと ができ、 また、 この親チームがチームマスタとしてメンバ Aを指名してい ると見なすことができる。 まず、 メンバ C 5からのサブチーム作成指示に従って、 チームデータリ ス ト管理装置 3 0 6がサブチーム作成要求をチームデータリス ト保管装置 3 1 δに送出する （ステップ S 1 1 δ )。 チームデータリス ト保管装置 3 1 δは記憶装置 3 2 δからォ一ソリティデータ 1 0 1 d δ及びォ一ソリテ イリス ト 1 0 1 u δを取得して、 これらをチームデータリス ト管理装置 3 0 δに送出する。 その際、 チームデータリス ト保管装置 3 1 δはチーム 1 0 1 6の配下にサブチーム （即ち、 図 4 0に示すチーム 1 0 2 δ ) があれ ばそれらチームに関するチームデータリス トも併せてチームデータリス ト 管理装置 3 0 όへ送出する （ステップ S 1 2 δ )。 チームデータリス ト管 理装置 3 0 6では、 AUD · AU L変更機能 3 8 δがメンバ C δからの指 示に基づいて、 親チーム I Dをチーム 1 0 1 0， チーム I Dをチーム 1 0 3 δ , チームマスタをメ ンバ Xとしたオーソリティデータ 1 0 3 d δを作 成するとともに、 チームマスタをメンバ Xとしたォ一ソリティ リス ト 1 0 3 u a δを作成する。 次に、 AUD · AU L変更機能 3 8 όは作成したォ —ソリティ リス ト 1 0 3 u a Sをォーソリティデータ 1 0 3 d δ と一緒に してデジタル署名機能 3 9 δに引き渡す。 デジタル署名機能 3 9 δは、 秘密鍵ファイルや秘密鍵の記録された I C カード等からメンバ Cに関する秘密鍵を取得し、 これを基に AUD · AU L変更機能 3 8 δから送られたォ一ソリティデータ 1 0 3 d δ及びォーソ リティ リス ト 1 0 3 u a 0に対して要求者たるメンバ Cのデジタル署名を 90 行う。 この時点ではォーソリティ リス ト 1 0 3 u a 0のデジタル署名はチ ームマスタ Xのものではなく、 サブチーム作成者のデジタル署名になって いる （以上、 ステップ S 1 3 δ；)。 次に、 デジタル署名機能 3 9 δは、 チ ーム 1 0 3 δについて作成されたォーソリティデータ 1 0 3 d δ及びォ一 ソリティリス ト 1 0 3 u a Sをチームデータリス ト保管装置 3 1 δに送出 して、 これらの保存要求を行う （ステップ S 1 4 S )。 チームデータリス ト保管装置 3 1 δでは、 権限確認機能 3 5 δが図 4 2 のフローチャートに示される権限確認を行う。 まず、 権限確認機能 3 5 δ は保存要求を行った要求者がメンバ Cであることを識別 （ステップ S 3 1 δ ) し、 チ一ム 1 0 1 δに関するォーソリティデータ 1 0 1 d δ及びォ一 ソリティリス ト Ι Ο Ι ια δを基に、 メンバ Cがチーム 1 0 1 όのチームマ スタ又はサブォ一ソリティであるかどうか調べる （ステップ S 3 2 δ )。 この場合、 メンバ cはチーム 1 0 1 δのサブォーソリティであるため、 正 当な権限を持つ者によって作成されたデータの保存要求と判断 （同ステツ プの判断結果が "YE S ") する。 ちなみに、 同ステップの判断結果が "N O" となる場合には改竄ないしは不正行為が存在しているため、 権限確認 機能 3 5 6は要求された保存動作を行うことなく処理を中止する。 次に、 権限確認機能 3 5 δは作成されたサブチーム 1 0 3 δのォ一ソリ ティデータ 1 0 3 d δ及びォ一ソリティ リス ト 1 0 3 u a 0のデジタル署 名がともに要求者たるメンバ Cのものであることを確認する （ステップ S 3 3 δ )。 この場合は、 前述したように何れもメ ンバ Cがデジタル署名し ているため同ステップの判断結果は "Y E S" となり、 権限確認機能 3 5 δは正常な権限でサブチームが作成されたものと最終的に判断して、 作成 されたサブチームのォ一ソリティデータ 1 0 3 d δ とォーソリティ リス ト 91 .
1 0 3 u a 6を記憶装置 3 2 δに保存する （ステップ S 3 4 S )。 ちなみ に、 ステップ S 3 3 δの判断結果が "NO" となる場合には改竄ないしは 不正行為が存在しているため、 権限確認機能 3 5 όは要求された保存動作 を行うことなく処理を中止する （なお、 以上の処理は図 4 1のステップ S 1 5 δに相当）。 以上の手順によってサブチームの作成が完了する。 この後、 チーム 1 0 3 δのチームマスタたるメンバ Xから当該チームに 対して、 情報共有のメンバやサブチーム作成権限者の設定といった管理要 求があったものとする。 なお、 ここでは一事例としてチーム 1 0 3 δのサ ブォ一ソリティとしてメンバ W及びメンバ Vを新たに登録する場合につい て説明する。 図 4 1に示すように、 まずチームデータリ ス ト管理装置 3 0 δは、 メンバ Xから指示された管理要求に基づいて、 親チーム 1 0 3 δに 関するチームデータリス 卜をチームデータリス ト保管装置 3 1 δに要求す る （ステップ S 1 6 S )。 すると、 チームデータリス ト保管装置 3 1 δは 要求内容をもとにしてサブチ一ム 1 0 3 δのほかル一トチームに至るまで の全ての親チーム （この場合はルートチームたるチーム 1 0 1 δのみ） に 関するチームデータリス トをそれぞれチームデータリス 卜管理装置 3 0 0 側に転送する （ステップ S 1 7 δ )。 チームデータリス ト管理装置 3 0 δ では、 リス ト正当性確認機能 3 7 δが図 7 όのフローチヤ一トに示される 処理手順に従って、 転送されてきたリス トの正当性を調べる （ステップ S 1 8 δ )0 まず、 リス ト正当性確認機能 3 7 δは、 管理対象であるチーム 1 0 3 δ のォ一ソリテイデ一タ 1 0 3 d δ及びォ一ソリティ リス ト 1 0 3 u a Sの デジタル署名を参照してそれらが改竄されているかどうか確認 （ステップ S 4 1 δ ) し、 改竄があれば不正行為があったものとして管理要求に関わ 92 . る処理を中止する （同ステップの判断結果が "NO")c —方、 同ステップ の判断結果が "Y E S" であって改竄がなければ、 リ ス ト正当性確認機能 3 7 δは、 ォーソリティデータ 1 0 3 d δからメンバ Xがチーム 1 0 3 δ のチームマスタであることを確認できる。 ここで、 通常であれば、 リス ト 正当性確認機能 3 7 δはォーソリティ リス ト 1 0 3 u a Sからそのデジタ ル署名者がチームマスタたるメ ンバ Xであることを確認する。 しかし、 前 述したようにこの時点はサブチーム作成途上の過渡期になっており、 ォー ソリティリス 卜 1 0 3 u a 5のデジタル署名者がサブチーム作成者である メンバ C δになっているので、 メンバ Cがサブチームを作成する正当な権 利を持っているかどう力 は、 後述する処理 （ステップ S 4 5 δ ) で、 メン バ Cが親チーム 1 0 1 δのチームマスタもしくはサブォーソリティとして 登録されているか調べることで確認する （ステップ S 4 2 δ )。 次に、 リス ト正当性確認機能 3 7 δはォ一ソリティデータ 1 0 3 d δの 親チーム I Dから親チームがチーム 1 0 1 δであることを知り （ステップ S 4 3 δ )、 親チームのォ一ソリティデータ 1 0 1 d δ及びォ一ソリティ リス ト 1 0 1 u δのデジタル署名が改竄されているかどうか調べる （ステ ップ S 4 4 0 )c そしてこれらの何れかでも改竄されていれば、 不正行為 があったとしてリス ト正当性確認機能 3 7 6は処理を中止する （同ステツ プの判断結果が "NO") 力；、 同ステップの判断結果が "Y E S " であつ て改竄がなければ、 引き続いてチーム 1 0 3 δの作成者が親チームのチー ムマスタ又はサブォ一ソリティであるかどうかを確認する （ステップ S 4 5 δ )。 この場合、 チーム 1 0 3 δのオーソリティデータ 1 0 3 d δのデ ジタル署名者はメンバ Cであり、 また、 親であるチーム 1 0 1 δのォーソ リティ リス ト 1 0 1 U 0からメンバ Cが親チームのサブォーソリティとし て登録されていることが分かり、 チーム 1 0 3 δが正当な作成権限を持つ 93 - 者によって作成されていることが確認できる（同ステップの判断結果が" Y E S ")。 なお、 同ステップの判断結果が " N O " であれば、 リ ス ト正当性 確認機能 3 7 6は不正行為があったものとして処理を中止する。 次に、 リス ト正当性確認機能 3 7 δは親であるチーム 1 0 1 δがルート であるかどうか調べるが、 この場合はチーム 1 0 1 δのオーソリティデー タ 1 0 1 d δの親チーム I D力； " R o o t δ " であることからルートチー ムであることが分かる （ステップ S 4 6 δの判断結果が " Y E S "；)。 そこ で、 リス ト正当性確認機能 3 7 δはチーム 1 0 1 δのォ一ソリティデータ 1 0 1 d δを調べることでそのチームマスタがメンバ Αであることが分か る。 そして、 このメンバ Aによってオーソリティデータ 1 0 1 d δ及びォ ーソリティ リス ト 1 0 1 U 0がデジタル署名されていることから、 チーム 階層がチームマスタ Αの下で正当に管理されていることを確認できる （ス テツプ S 4 7 δ )。 最後に、 メンバ X自身がチームデータリス ト管理装置 3 0 6を操作して、 ル一 トチーム 1 0 1 όのチームマスタ Αが管理するチ —ム階層の下に、 情報共有などのチームデータリ ス 卜の利用や階層化され たチームの利用が為されていることを承認して、 この旨をリ ス ト正当性確 認機能 3 7 δに通知する。 以上の手順により、 リ ス ト正当性確認機能 3 7 δは、 チーム 1 0 1 δの チームマスタ Αの指名したサブォーソリティ Cがチーム 1 0 3 δに関する ォーソリティデータ及びォーソリティリス トを作成しており、 チームデ一 タ リス ト保管装置 3 1 δから正常な状態でこれらチームデータリス トが取 得されていることを確認できる。 そこで、 リ ス ト正当性確認機能 3 7 δは チームデータリス ト保管装置 3 1 6から転送されたチームデータリス トを A U D . A U L変更機能 3 8 δに渡す。 なお、 図 4 3のステップ S 4 6 δ 94 で親チームがルー トチームと判断されなかった場合、 例えばチーム 1 0 3 δのサブチームであるチーム 1 0 4 5に対して管理要求を行った場合、 リ ス ト正当性確認機能 3 7 όは対象とするチームを親チームに変更してチ一 ム階層をルートチームに向かって一つ上がり （ステップ S 4 9 6 )、 親チ —ムがルートチームたるチーム 1 0 1 δになる （ステップ S 4 6 δの判断 結果が "Y E S") までステップ S 4 2 S〜S 4 6 S及びステップ S 4 9 δから成るループを繰り返して実行する。 次に、 AUD · AU L変更機能 3 8 δはチーム 1 0 3 5のォ一ソリティ リス ト 1 0 3 u a 0に対して、 サブォ一ソリティとしてメンバ W及びメン バ Vを加えたオーソリティ リス ト 1 0 3 u δを作成し、 これをォ一ソリテ イデ一タ 1 0 3 d δ とともにデジタル署名機能 3 9 6に渡す。 デジタル署 名機能 3 9 6は前述した秘密鍵ファイル等からチームマスタ Xに関する秘 密鍵を取得し、 渡されたォ一ソリティリス ト 1 0 3 u 5に対してチームマ スタ Xのデジタル署名を行ったのち （以上、 ステップ S 1 9 6 )、 これを ォーソリティデータ 1 0 3 d δ とともにチームデータリス ト保管装置 3 1 δに転送してこれらチームデータリス トに関する保存要求を行う （ステツ プ S 2 0 δ )。 チームデータリス ト保管装置 3 1 δにおいて、 権限確認機能 3 5 δはチ —ムデータリスト管理装置 3 0 δからの保存要求に対し、 記憶装置 3 2 δ に保管されているチ一ム 1 0 1 δに関わるチームデータリス 卜とクライァ ント側から転送されてくるチーム 1 0 3 δに関わるチームデータリス トに 基づいて、図 4 4のフローチヤ一トで示される権限確認を行う。すなわち、 まず権限確認機能 3 5 δは保存要求を指示した要求者がメンバ Xであるこ とを識別 （ステップ S 5 1 0 ) し、 転送されてきたォーソリティデータ 1 95 -
0 3 d δ及びォーソリティ リス ト 1 03 u 6をもとにして、上記要求者が、 チ一ム 1 03 δのチームマスタ， 親であるチーム 1 0 1 όのチームマスタ 又はサブォ一ソリティの三者のうち何れかに一致するかどうかを確認する。 この場合は要求者たるメンバ Xがチーム 1 0 3 δのチ一ムマスタとして登 録されている （ステップ S 5 2 6の判断結果が "YE S ") ので、 権限確 認機能 3 5 δは要求者が保存要求に対する正当な権限を持っていると判断 する。 ちなみに、 同ステップの判断結果が "NO" であれば、 権限確認機 能 3 5 δは要求者に正当な権限が与えられていないものとして処理を中止 する。 次に、 権限確認機能 3 5 δはォ一ソリティデータ 1 0 3 d δのデジタル 署名者が親チームのチームマスタ又はサブォーソリティの何れかに一致す るかどうか確認する。 この場合、 オーソリティデータ 1 03 d 0のデジタ ル署名者はメンバ cであって親チーム 1 0 1 δのサブォーソリティである
(ステップ S 53 δの判断結果が "YE S") ため、 権限確認機能 3 5 δ は要求者が保存要求に対する正当な権限を持っていると判断する。 ちなみ に、 同ステップの判断結果が "NO" であれば、 権限確認機能 3 5 δは改 直や不正行為があったものとして処理を中止する。 次に、 権限確認機能 3 5 δは、 オーソリティリス ト 1 03 u 6のデジタル署名者がォ一ソリティ デ一タ 1 03 d δに登録されているチームマスタと一致するかどうかを確 認する。 この場合、 オーソリティ リスト 1 0 3 u δのデジタル署名者はォ —ソリティデータ 1 03 d όの示すチームマスタ Xである （ステップ S 5 4 δの判断結果が "YE S") ことから、 権限確認機能 3 5 δは正常な権 限を持つ者によってチーム 1 0 3 δが作成されたものと最終判断を下して、 チームデータリス ト管理装置 3 0 όから転送されたチームデータリス トを 記憶装置 3 2 δに保存して、 チーム 1 03 δに関するチームデータリス ト 96 の内容を更新する （ステップ S 5 5 S ) C なお、 ステップ S 5 4 δの判断 結果が " N O " であったならば、 権限確認機能 3 5 δは改竄や不正行為が あったものとして処理を中止し、 上述したステップ S 5 5 δにおける保存 処理は実施しない。 以上のようにして、 サーバ S V δ側に保管されているチームデータリス トに基づいて、 メンバ Xが間違いなくル一トチームのチームマスタ Αによ る管理体系の中で正当にチーム 1 0 3 δのチ一ムマスタとして任命されて いることが検証できる （図 4 1のステップ S 2 1 δ )。
〈サブチームのチームマスタの変更〉
次に、 サブチームのチームマスタを変更するための処理手順について図 4 5を参照して説明する。 ここではルートたるチーム 1 0 1 δにサブォー ソリティとして登録されているメンバ Βが、 サブチームであるチーム 1 0 3 δのチームマスタをメンバ Xからメンバ Ζへ変更する場合を例に挙げる こととする。 これは人事一課長が異動になったために、 人事部長の代わり に部長代理が課長を変更する場合などに相当する。 まず、 チームデ一タリ スト管理装置 3 0 δはサブチーム 1 0 3 0に関わるチームデータリス トの 変更要求をチームデータリス ト保管装置 3 1 6に送出する （ステップ S 6 1 δ )。 これにより、 チームデータリス ト保管装置 3 1 δは図 4 1 のステ ップ s 1 2 δ と同様にチーム 1 0 1 δ とその配下のサブチームに関するチ
—ムデ一タリストをチームデータリス ト管理装置 3 0 δ側に転送する （ス テツプ S 6 2 δ )。 チームデータリス ト管理装置 3 0 6では、 リス 卜正当性確認機能 3 7 δ が図 4 3で説明した処理手順に従って転送されてきたチームデータリス ト 97 の正当性の検証を行い （ステップ S 63 6 )、 その正当性が検証できた場 合に転送されてきたチームデータリス トを AUD · A U L変更機能 3 8 δ に引き渡す。 AUD · AU L変更機能 3 8 δは、 メンバ Βからの指示内容 に従って、 引き渡されたチームデータリス トのうちオーソリティデータ 1 03 d δについてチームマスタをメンバ Xからメンバ Ζに変更して、 この 変更されたオーソリティデータと引き渡されたオーソリティリストとをデ ジタル署名機能 3 9 δに送る。 デジタル署名機能 3 9 δは送られたチーム データリス 卜に対してそれぞれ前述した秘密鍵ファイル等からメンバ Βに 関する秘密鍵を取得してデジタル署名を施し、 それによつてォ一ソリティ データ 1 03 d b δ及びォ一ソリティリス ト 1 0 3 u b 6を作成 （ステツ プ S 64 6 ) したのち、 これらチームデータリ ス トをチームデータリ ス ト 保管装置 3 1 δに転送して保存要求を行う （ステップ S 6 5 δ )0 チームデータリス 卜保管装置 3 1 6では、 権限確認機能 3 5 δが転送さ れてきたチームデータリス トを基に図 44に示した手順に従った権限確認 を行って、 その正当性が確認された場合に、 転送されてきたチームデータ リス トを記憶装置 3 2 δに保存する。 ここで、 サブチーム作成時 （図 4 1 のステップ S 2 1 S ) と相違する点は、 チームマスタ変更処理においては ォ一ソリティ リス ト 1 0 3 u b Sのデジタル署名者であるメンバ Bとォ一 ソリティデータ 1 0 3 d b δで指名されているチ一ムマスタたるメンバ Ζ が異なっていることである （ステップ S 5 4 όの判断結果が "NO" とな るケース） c そこでこの場合、 権限確認機能 3 5 δはォーソリティ リス ト 1 03 u b δのデジタル署名者が親チームに登録された管理者たるチーム マスタ Α, サブオーソリティ Β, サブオーソリティ Cの何れかに一致して いれば、 正当な権限を持つ者によるデジタル署名であると判断する。 そし て以上のようにして、 サ一ベ s V δ側にはチーム 1 0 3 δに関わるチーム 98 データリス トとして作成時間の異なる 2組のォ一ソリティリス ト及びォ一 ソリティデータ， 即ちチームマスタ変更前後の各チームデータリス トが保 存される。 その後、 チームデータリ ス ト保管装置 3 1 δは、 チーム 1 0 3 δの新たなチームマスタであるメンバ Ζのデジタル署名をォ一ソリティ リ スト 1 0 3 u b δに付与するために、 ォ一ソリティデータ 1 0 3 d b δ及 びォ一ソリティリス ト 1 0 3 u b 5をチームデータリス ト管理装置 3 0 δ に転送する （ステップ S 6 6 δ )。 チームデータリ ス ト管理装置 3 0 δでは、 リ ス ト正当性確認機能 3 7 δ が図 4 3の処理手順に従って、 転送されてくるチームデータリ ス 卜の正当 性を検証したのち、 これを AU D · AU L変更機能 3 8 δを介してデジタ ル署名機能 3 9 δに渡す。 デジタル署名機能 3 9 δは、 前述した秘密鍵フ アイル等からメンバ Ζに関する秘密鍵を取得し、 これを基にオーソリティ リス ト 1 0 3 u b 5に対してメンバ Zのデジタル署名を行ってォ一ソリテ イリス ト 1 0 3 u c Sを作成する （ステップ S 6 7 δ )。 次いで、 デジタ ル署名機能 3 9 6は作成されたォーソリティ リス ト 1 0 3 u c 5をォーソ リティデータ 1 0 3 d b ό とともにチームデータリス 卜保管装置 3 1 δに 転送する （ステップ S 6 8 δ )。チームデータリスト保管装置 3 1 6では、 権限確認機能 3 5 δが転送されてきたチームデータリス トを基に図 4 4の 処理手順に従って権限確認を行い、 その正当性が確認された場合に転送さ れてきたチームデータリス トを記憶装置 3 2 6に保存して、 チーム 1 0 3 δに関わるチームデ一タリス トの更新処理を行う。 以上によって、 チーム マスタが正常な手順を踏んで変更されたことになる。
〈サブオーソリティの変更〉
次に、 サブォ一ソリティを変更するための処理手順について図 4 6を参 99 照して説明する- ここでは、 ルートであるチーム 1 0 1 δのチームマスタ Α δ力；、 このチーム 1 0 1 δでサブォーソリティとして登録されているメ ンバ Β δの作成権限を剥奪する場合を例に挙げて説明する。 これは、 部長 代理が異動になるなどして、 人事部長がこの部長代理を人事部から除外す る場合などに相当する。 なお、 同図では図 4 5に示したチームマスタ変更 によってサブォーソリティ Β δが作成者となっているチーム 1 0 3 δを前 提としている。 また、 同図では、 サブオーソ リティ Βの作成権限が削除さ れるのに伴ってチーム 1 0 3 0を削除してしまう場合と、 チーム 1 0 3 0 を継続させる場合の 2つのケースを併せて図示してある。 したがって、 メ ンバ Αがチームデータリス ト管理装置 3 0 6に対して要求を指示する場合 にはチーム 1 0 3 δを存続させるかのか否かも併せて指示するようにして いる。 まず、 チ一ムデータリス ト管理装置 3 0 δはチーム 1 0 1 δに登録され ているサブオーソリティ Β δに対する変更要求 （削除要求） をチームデー タリス ト保管装置 3 1 δに対して送出する （ステップ S 7 1 0 ): これに より、 チームデータリス ト保管装置 3 1 δはチーム 1 0 1 δの配下にある サブチームのォ一ソリティデータを参照して、 それらサブチームの中から サブチーム Βが作成者となっているチーム 1 0 3 δを検索したのち、 チー ム ι ο ΐ δ とチーム ΐ 0 3 δに関するチームデータリス トをチームデータ リス ト管理装置 3 0 δ側に転送する （ステップ S 7 2 0 )。 チームデータ リス ト管理装置 3 0 δでは、 リス ト正当性確認機能 3 7 δが図 4 3で説明 した処理手順に従って、 転送されてきたチームデータリス 卜の正当† の検 証を行い、 その正当性が検証できた場合に転送されてきたチームデータリ ス トを AUD · AU L変更機能 3 8 8に引き渡す。 100
AUD . AU L変更機能 3 8 δはメンバ Αからの指示内容に基づいて、 引き渡されたチームデータリス トのうち、 ォ一ソリティ リス ト Ι Ο Ι ια δ に記述されているサブォーソリティの中からメンバ Βを削除したォ一ソリ ティリス ト l O l u b Sを作成する （ステップ S 73 δ )。 これに加えて、 AUD · A UL変更機能 3 8 δはォ一ソリティデータ 1 03 d b δに付与 されているメンバ Βのデジタル署名を削除してォーソリティデータ 1 03 d c δを作成する （ステップ S 74 S )。 この後、 AUD ' AU L変更機 能 3 8 δはォーソリティデータ 1 03 d c δ とォーソリティ リス ト 1 03 u c βをデジタル署名機能 3 9 6に送出する。 デジタル署名機能 3 9 όはメンバ Αからの指示内容に従って以下の 2通 りの処理の何れかを行う。 第 1に、 チーム 1 03 δを継続させる要求が来 ているのであれば、 デジタル署名機能 3 9 δはチーム 1 03 δの存在をメ ンバ Αが承認したものと見なし、 前述した秘密鍵ファイル等からメンバ A に関する秘密鍵を取得し、 これを基にォ一ソリティデータ 1 0 3 d c δに メンバ Αのデジタル署名を添付してォ一ソリティデータ 1 03 d d δを作 成する （ステップ S 7 5 0 )。 次いで、 デジタル署名機能 3 9 δはォ一ソ リティデータ 1 0 1 (1 δ , 1 03 d d δ及びォーソリティリス ト l O l u b δ , 1 03 u c Sをチームデータリス ト保管装置 3 1 δに転送してこれ らチ一ムデータリ ス トの保存要求を行う （ステップ S 7 6 0 )。 チームデ —タリスト保管装置 3 1 δでは、 権限確認機能 3 5 δが転送されてきたチ —ムデータリ ス トを基に図 44に示した手順に従った権限確認を行って、 その正当性が確認された場合に、 転送されたチームデ一タ リス トで記憶装 置 3 2 0の内容を更新する （ステップ S 7 7 S )。 第 2に、 チーム 1 0 3 όを消去する旨の要求が来ているのであれば、 デ 101 ジタル署名機能 3 9 δはチーム 1 0 1 δに関するチームデータリス ト， す なわちォーソリティデータ 1 0 1 d δ及びォ一ソリティ リス ト l O l u b δをチームデータリス ト保管装置 3 1 δへ転送するとともに、 チーム 1 0 3 δを無効にする旨の命令をチームデータリス ト保管装置 3 1 δに送出す る （ステップ S 7 8 δ )。 チームデータリス ト保管装置 3 1 δでは、 権限 確認機能 3 5 6が記憶装置 3 2 δに保存されているォーソリティリス ト 1 0 1 u 6と送られてきたォ一ソリティリス ト l O l u b Sを照合すること でサブオーソリティ Bの削除を認識することができる。 これに加えて、 権 限確認機能 3 5 δはオーソリティデータ 1 0 1 d δ及びォ一ソ リティリス ト 1 0 1 u b δの内容から、 チームマスタがメンバ Αであって且つこれら チームデータリス 卜が何れもこのメンバ Aによつてデジタル署名されてい ることが分かる。 こうしたことから、 権限確認機能 3 5 δはチームマスタ Αが正当な権限でサブォーソリティ B δを削除したものと判断して、 ォー ソリティデータ 1 0 1 d δ及びォ一ソリティ リス ト l O l u b Sの内容で 記憶装置 3 2 δ中のチーム 1 0 1 0のチームデータリス トを更新する。 次 いで、 権限確認機能 3 5 δは記憶装置 3 2 δ上からチーム 1 0 3 δに関わ るオーソリティデータ及びオーソリティ リ ス トを削除する （以上、 ステツ プ S 7 9 ό )。 以上によって、 サブォーソリティ Βの作成権限がサーバ S V δ上のチームデータリス トから削除されたことになる。
〈サブチームの削除〉
次に、 サブチームを削除するための処理手順について図 4 7を参照して 説明する。 ここでは、 ルートであるチーム 1 0 1 δにサブォ一ソリティと して登録されているメ ンバ Cが、 前述した図 4 1 の処理手順で作成したチ ーム 1 0 3 δを削除する場合を例に挙げて説明する。 これは、 人事部の下 にある人事一課が廃止されたために、 人事部長代理が課の廃止に関わる業 102 務を行う場合などに相当する。 ここで、 メンバ Cは、 サブチームであるチ —ム 1 0 3 δの親に相当するチーム 1 0 1のサブォ一ソリティの権限でも つてチ一ム 1 0 3 δを削除するため、 自分が間違いなくメンバ C本人であ ることをチームデータリス ト保管装置 3 1 δに対して証明してやる必要が ある。 そのため、 チームデータリ ス ト管理装置 3 0 δは後述するようにチ ームデータリスト保管装置 3 1 δに対してメンバ Cのデジタル署名を通知 するようにしている。 さて、 まずメンバ Cがチームデータリス ト管理装置 3 0 δに対してチー ム 1 0 3 δ の削除指示を行うと、 チームデータリス ト管理装置 3 0 δはデ ジタル署名機能 3 9 δによってメンバ Cのデジタル署名を作成したのち、 チーム 1 0 3 δをメンバ Cの権限で削除する旨の命令とメンバ Cのデジタ ル署名を組にしてチームデータリス ト保管装置 3 1 δへ転送する （ステツ プ S 8 1 δ )。 なお、 デジタル署名を添付する以外の方法として、 削除命 令の転送時に証明する 「シェイクハンド」 あるいは 「チャレンジレスボン ス J と呼ばれる方法 （詳細は後述） を採用することも考えられるが、 ここ ではデジタル署名を用いた方法に沿って説明を行うものとして、 最後にシ ェイクハンドについて説明することとする。 チームデータリス ト保管装置 3 1 δがチームデータリスト管理装置 3 0 δからチーム 1 0 3 δの削除命令を受け取ると、 権限確認機能 3 5 δはチ
—ム 1 0 1 δ及びチーム 1 0 3 δに関するチームデータリス トを参照して、 チーム 1 0 1 δに登録されているサブォ一ソリティ Cがチーム 1 0 3 δの 作成者であることを知る。 また、 権限確認機能 3 5 δはオーソリティデ一 タ 1 0 3 d δに記述されたメンバ Cのデジタル署名と削除命令に添付され ているメンバ Cのデジタル署名を照合して、 これらが一致していることこ 103 とを確認することにより、 削除を指示した者が間違いなくメンバ C本人で あることについて確証を持てる。 こうして、 権限確認機能 3 5 δは正当な 権限で発行された削除命令であるものと判断して、 記憶装置 3 2 δ上から チーム 1 0 3 δに関するォーソリティデータ 1 0 3 d δ及びォーソリティ リス ト 1 0 3 u δを削除する （以上、 ステップ S 8 2 0 )。 以上によって、 サブォ一ソリティ Cによるチーム 1 0 3 δの削除処理が完了したことにな る。 ところで、 メンバ Αはチーム 1 0 1 δのチームマスタであることから、 サブォ一ソリティ Cの代わりにサブチームたるチーム 1 0 3 5を削除する 正当な権限を有している。 この場合に、 メ ンバ Αがチームデ一タリス ト管 理装置 3 0 δに対してチーム 1 0 3 δ の削除指示を行うと、 チームデータ リス ト管理装置 3 0 δはデジタル署名機能 3 9 δによってメンバ Αのデジ タル署名を作成して、 チーム 1 0 3 δをチームマスタ Αの権限で削除する 旨の命令とメンバ Aのデジタル署名をチームデータリス ト保管装置 3 1 δ へ転送する （ステップ S 8 3 0 )。 チームデータ リ ス ト保管装置 3 1 δに おいて、 権限確認機能 3 5 δはチーム 1 0 1 0及びチ一ム 1 0 3 0に関す るチームデータリストを参照することで、 チーム 1 0 1 δに登録されてい るサブオーソリティ Cがチーム 1 0 3 δの作成者であり、 且つ、 このサブ ォ一ソリティ Cは親チーム 1 0 1 0のチームマスタ Αによってサブォ一ソ リティとして指名されたものであることが分かる。 また、 権限確認機能 3 5 6はォーソリティデータ 1 0 1 d δに記載されているメンバ Αのデジタ ル署名と削除命令に添付されているメンバ Aのデジタル署名を照合するこ とで、削除を指示した者が間違いなくメンバ A本人であることを確認する。 こう して、 権限確認機能 3 5 όは正当な権限で発行された削除命令である ものと判断して、 記憶装置 3 2 δ上からチーム 1 0 3 δに関するォ一ソリ 104 ティデータ 1 0 3 d δ及びォ一ソリティ リス ト 1 0 3 U 0を削除する （以 上、 ステップ S 8 4 δ )c 以上によって、 チームマスタ Aによるチーム 1 0 3 δの削除処理が完了 したことになる。 なお、 上述したメンバ以外にも、 例えばチーム 1 0 1 δ にサブォーソリティとして登録されているメンバ Βがサブチームであるチ —ム 1 0 3 δを削除することも可能である。 最後に、 図 4 8を参照しつつ、 上述したシェイクハンドないしチヤレン ジレスポンスの処理手順の詳細を説明する。 まず、 クライアント C L Sは サーバ S V δにアクセスする際にユーザ （図 4 7の場合で言えばメンバ C またはメンバ Α) のユーザ名およびュ一ザ公開鍵をサーバ S V δに送付す る （ステップ S 1 0 1 0 )。 サーバ S V 0は乱数を発生させて内部に記憶 するとともにこの乱数をユーザ公開鍵で暗号化（ステップ S 1 0 2 δ ) し、 喑号化されたデータを 「チャレンジデータ」 としてクライアント C L Sに 送信する （ステップ S 1 0 3 0 )。 クライアン ト C L δはサーバ S V δ力 ら送られたチャレンジデータをユーザ公開鍵に対応した秘密鍵で複号化 (ステップ S 1 0 4 δ ) し、 得られた複号化データを 「チャレンジレスポ ンス」 としてサーバ S V δに返送する （ステップ S 1 0 5 0 )。 サーバ S ν δはクライアント C L 6から送られたチャレンジレスポンスとステップ S 1 0 2 δで発生させた乱数とを比較して通信相手を確認する。すなわち、 両者が一致すればステップ s 1 0 1 δで送付されたユーザ公開鍵に対応す る秘密鍵を知っている者が通信相手であることを確認 （認証成功） するこ とができる。 これに対し、 両者が不一致であれば通信相手が正当な権限を 持った者でない可能性のある （認証失敗） ことがわかる （以上、 ステップ s 1 0 6 δ )。 この後、 サーバ s V δはステップ S 1 0 6 δで得られた確 105 認結果 （認証成功または認証失敗） をクライアン ト C L δに通知する （ス テツプ S 1 0 7 δ )。 以上のようにすることで、 デジタル署名を添付した 場合と同じく、 メンバ Cゃメンバ Αが本人であることをサーバ S V δ側で 確かめることができる。 なお、 クライアント C L δからサ一バ S V δへユーザ公開鍵を送る代わ りに 「ュ一ザ公開鍵番号」 を送るようにしても良い。 ここで言うユーザ公 開鍵番号はユーザ本人を識別 ·認証するための情報であって、 各ュ一ザ公 開鍵に予め付与されているシリアル番号のことである。 さらに詳しく説明 すると、 ユーザ公開鍵番号はユーザ公開鍵を一意に識別するための各ユー ザ公開鍵に対応した情報であって、 例えば、 上述した認証局から発行され た証明書に含まれている当該証明書のシリアル番号である。 また、 ユーザ 本人を識別 ·認証するための情報としては、 いま述べたユーザ公開鍵番号 以外にも、 実際に鍵作成者本人を識別する I Dや名前などの様々な情報を 利用することができる。
〔第 4 一 2実施形態〕
図 4 9は本実施形態によるチームの階層化について示したものであって、 チーム内のメンバの利用できるアプリケーションがチーム毎に異なる形態 を実現したものである。 同図では、 図 4 0に示したチームのうちチーム 1 0 1 δ 〜 1 0 3 δに対応するものだけを示してある。 ォーソリティ リス ト 及びォーソリティデ一タに関しては図 4 0に示したものと同じであるが、 このほか、 各チームにはメンバリス トの代わりにメンバリス トの内容を包 含するアプリケーションリス ト 1 0 1 a ό ， 1 0 2 a 6 , 1 0 3 a δが設 けられている。 すなわち、 これらアプリケーションリス トには、 各チーム に属するメンバの利用可能なシステムのほか、 そのチームに属するメ 106 の一覧が記載されている。 アプリケ一ションについては例えばチ一ム 1 0 1 δのアプリケ一ションリス ト 1 0 1 a δには人事管理システム， 経理シ ステム， スケジュール， ファイル共有システムが登録されている。 また、 メンバ一覧については図 4 0のメンバリス トに記載されているものと同じ である。 この第 4一 2実施形態では、 第 4一 1実施形態と同様にチームの生成に 関しては親チームの干渉を受けるものの、 アプリケ一ションリス トは各チ —ムのチームマスタがそれぞれデジタル署名するので、 チーム内の管理は 親チームからの干渉を受けずに行うことができる。 つまり、 チーム内で利 用可能なアプリケ一ションをどのメンバで共同利用するかといったことは、 チームマスタが親チームの管理者から独立して行うことができる。例えば、 チ一ム 1 0 1 0のサブチームであるチーム 1 0 2 δでは、 アプリケーショ ンリス ト 1 0 2 a Sのデジタル署名はチーム 1 0 2 δのチームマスタであ るメンバ Υ δがデジタル署名しており、 チーム 1 0 1 δの管理者であるチ
—ムマスタ A δやサブォーソリティ Β δ ， c δの干渉を受けなくて済む。
〔第 4一 3実施形態〕
本実施形態では、 サブチームを管理するという観点から見たメンバ， サ ブオーソリティ， チームマスタという上述の権限分担に加えて、 情報を共 有してゆくためのチーム内での管理権限分担として各チームに属する者を メンノく， サブ、マスタ
， チームマスタの 3種類に分類している。 このうち、 サブマスタはチーム マスタによって指名されたチーム内の管理者であって、 チ一ムマスタゃサ ブマスタを変更することは許されていない力 一般のメンバについて追加， 削除， 変更を行うことのできる者である。 一方、 チームマスタはサブマス 107 タ又はメンバの変更を行えるほ力 、 自身のチームマスタでさえ変更するこ とのできる者である。 他方、 サブマスタ及びチームマスタ以外の一般のメ ンバはメンバに提供される情報や機能を共有する者であって、 チームデ一 タリス 卜の内容に変更を加える等の権限はいつさい与えられていない。 な お、 サブマスタやチームマスタも特別な権限が与えられてはいるが、 チー ム内のメンバであることに変わりはなく、 その意味でサブマスタ又はチー ムマスタをメンバと呼ぶことがある。 図 5 0は本実施形態におけるチームの階層化について示したものである。 同図では、 図 4 0に示した第 4 - 1実施形態の各チームに対してさらにチ —ムマスタリストを加えてある。 こうすることで、 チーム毎に情報共有を 管理するとともに、 各チーム内の情報共有のメンバの管理を複数の管理者 が行えるようにしている。 図 5 0において、 チームマスタリス ト 1 0 1 t δ〜 1 0 4 t δは各チームに登録されているチームマスタ及びサブマスタ の一覧とチームマスタのデジタル署名が記載されている。 もっとも、 これ 以外にもチームマスタリ ス トには、 チームマスタ又はサブマスタの識別情 報， 公開鍵， 公開鍵 I D， チーム I D， チームマスタ リス トの作成時間を 示すタイムスタンプなどが含まれている。 このほ力 、 チームマスタ リス ト 3 4 δには、 チームに関する情報としてチームのメンバ数， チームの作成 された時間， チーム内の各メンバが利用することのできる各種機能などの 情報 （例えば、 上述したアプリケーションリス ト） も含まれており、 これ らを用いることで各チームに関する情報リソースの管理を同時に行うこと ができる。 チームマスタリス トのデジタル署名は、 各チームのチームマスタがチ一 ム作成時にデジタル署名し、 以後はずつとチームマスタのデジタル署名に 108 なっている。 これに対し、 メンバリストについては各チーム内のチームマ スタの他に、 サブマスタがこれを管理する権限を付与されているため、 チ ームマスタ以外にサブマスタのデジタル署名が為されている場合もある。 例えば、 メンバリス ト 1 0 1 m a δに関してはチーム 1 0 1 δのサブマス タとして登録されているメンバ Β δ のデジタル署名がなされている。一方、 チ一ム 1 0 2 δのように、 チームマスタリス ト 1 0 2 t δにサブマスタが 登録されていない場合にはメンバリスト 1 0 2 m a Sはチームマスタであ るメンバ B δがデジタル署名することになる。 この図 5 0ではサブチームの管理権限， メンバの管理権限をそれぞれォ —ソリティ リスト/ォーソリティデータ， チームマスタリス トに分割して いるため、 各チーム内でサブォーソリティとサブマスタに異なる者を割り 当てることができる。 例えば、 チーム 1 0 3 δではメンバ W及びメンバ V がサブォーソリティであり、 メンバ Υ及びメンバ Ζがサブマスタであるた め、 サブチームの管理とメンバ管理を異なる者が担当して負荷分散を図る こともできる。 もっとも、 実際にはサブオーソリティとサブマスタを同じ メンバにしてしまって良レ、 その場合はォ一ソリティ リストとメンバリス トを統合して一つのリ ス 卜にしてしまうことが可能となる。
〔第 4 一 4実施形態〕
上述した各実施形態では、 チームデータリス トを使用する都度、 チーム マスタが間違いなく 自分のチームマスタであるかどうかをユーザがクライ アン ト C L δ側で確認する必要がある。 例えば、 チームデータリス ト管理 装置 3 0 όを構成するコンピュータのディスプレイ上に、 "このリス トは 以下のメンバが管理者となって正常に管理されています。名前：メンバ Α。 組織： 三菱マテリアル株式会社。 作業を続行する場合は Ο Κボタンをマウ 109 スでクリックして下さい" などといったメッセージが表示される。 このよ うに、 ユーザは当該メッセージを目視で確認する必要が生じてくるため、 ユーザに対して煩わしい印象を与える可能性がないとは言えない。 こうし た点を改善するには以下の機能をリス ト正当性確認機能 3 7 δ と連携する 新たな機能として追加し、 あるいは、 リスト正当性確認機能 3 7 δの一機 能として組み込むようにすることで解決される。 すなわち、 ルートチーム 1 0 1 δにおけるチームマスタの公開鍵をチー ム毎に予めクライアント C L δ側の例えば公開鍵データべ一ス 4 1 δ (図 3 7参照） に登録しておき、 公開鍵管理機能 4 0 όが公開鍵データべ一ス 4 1 0からチーム 1 ◦ 1 ό のチームマスタに関する公開鍵を取得してこれ をリス ト正当性確認機能 3 7 δに通知する。 もしくは、 公開鍵データべ一 ス 4 1 δには公開鍵に関する情報として公開鍵を識別するためのシリアル 番号等を登録しておき、 公開鍵管理機能 4 0 6がこのシリアル番号を公開 鍵データベース 4 1 δから取得したのち、 これをもとにチームデータリス ト管理装置 3 0 0の外部 （例えばインターネッ ト上） に登録されている公 開鍵を別途取得してリス ト正当性確認機能 3 7 δに渡すように構成しても 良い。 一方、 リス 卜正当性確認機能 3 7 δは、 コンピュータのディスプレイ上 に上述したようなメッセージを出す代わりに、 公開鍵管理機能 4 0 δから 通知されるチ一ム 1 0 1 δのチームマスタの公開鍵に基づいて、 チームデ —タ リス ト保管装置 3 1 δから転送されてく るオーソリティデータ 1 0 1 d δに含まれているチームマスタのデジタル署名を確認するようにして、 当該デジタル署名が登録されているチームマスタのものかどうかを判断す る。 こうすることで、 ユーザがディスプレイ上の表示をもとに目視で確認 110 することなく、 ル一トチーム 1 0 1 δのチームマスタの正当性を検証でき るようになる。
なお、 チームマスタを確認するための情報としては公開鍵以外にも様々 な情報を利用できるのはもちろんである。 以上の通り、 チームを階層化するためのチームデータリス トを管理する チームデータリス ト管理プログラムを記録した記録媒体において、 チーム デ一タリス ト管理プログラムは、 （ 1 ) 所定の要求先に前記チームデータ リス トの操作要求を行う処理と、 （ 2 ) 前記操作要求に応じて、 操作対象 のチームからル一 トチームに至る各チームについて、 自チームの親チーム を表す識別子及び前記親チームの管理者のデジタル署名が含まれたォ一ソ リティデータと、 自チームの管理下にあるサブチームの管理権限者に関す る管理者情報及び自チームの管理者であるチームマスタ又は前記親チーム の管理者のデジタル署名が含まれたォ一ソリティ リス 卜を有するチームデ —タリス トを前記要求先から取得する処理と、 （3 ) 前記識別子を用いて 取得された各チームを前記ルートチームまで迪りながら各チームについて、 前記チームデータリス 卜のデジタル署名が改竄されていないこと及び前記 管理者情報を用いて権限を持つ者によるデジタル署名であることを確認し たのち、 ユーザによる前記ルートチームのチームマスタの承認を確認する 正当性確認処理と、 （4 ) 該正当性確認処理によって正当性が確認された 前記チームデータリス トに対して前記操作要求に応じた変更を加える変更 処理と、 （5 ) 前記操作要求を行った指示者のデジタル署名を作成して、 前記変更処理によって変更されたチームデータリ ストに該デジタル署名を 添付して前記要求先に送出する処理とをコンピュータに実行させる。 また、 上述のチームデ一タリス ト管理プログラムにおいて、 前記正当性 1 11 確認処理は、 前記チームマスタにより自チーム内のメンバから指名された 者であって前記サブチームの管理権限を有する一人以上のサブォーソリテ ィと、 前記サブォ一ソリティの持つ権限に加えて前記サブォーソリティに 対する管理権限を有する前記チームマスタとに関する情報を前記管理者情 報として用いるものであっても良い。
また、 上述のチームデータリ ス ト管理プログラムは、 前記ルートチーム のチームマスタの本人識別を行うための識別情報を所定の場所から取得し て予め登録しておく処理と、 前記要求先から前記ルートチームのォ一ソリ ティデータが送られてくる度に、 予め登録されている前記識別情報を用い て、 該ォ一ソリティデータのデジタル署名が前記チームマスタのデジタル 署名であることを確認する処理とをさらにコンピュータに実行させるもの であっても良い。 一方、 チームを階層化するためのチームデータリス トを保管するチーム データリスト保管プログラムを記録した記録媒体において、 チームデータ リス ト保管プログラムは、 （ 1 ) 自チームの親チ一ムを表す識別子及び前 記親チームの管理者のデジタル署名が含まれたォ一ソリティデータをチー ム毎に予め記憶しておく処理と
、 ( 2 ) 自チームの管理下にあるサブチームの管理権限者に関する管理者 情報及び自チームの管理者であるチームマスタ又は前記親チームの管理者 のデジタル署名が含まれたォ一ソリティ リス トをチーム毎に予め記憶して おく処理と、 （3 ) 所定の要求元から前記オーソリティデ一タ及び前記ォ —ソリティ リス卜が少なく とも含まれたチームデータリ ストに対する操作 要求があつたときに、 該操作要求の指示者が要求権限を持つことを前記管 理者情報を用いて確認するとともに、 該操作要求が参照要求或いは削除要 求である場合は、 要求されたチームデータリス トを前記要求元へ返送し或 1 12 いは削除し、 該操作要求が更新要求である場合は、 前記要求元から送られ るチームデータリス 卜のデジタル署名が権限を持つ者によるデジタル署名 であることを前記管理者情報を用いて確認したのち、 前記送られたチーム データリス 卜で記憶されている前記ォーソリティデータ及び記憶されてい る前記ォ一ソリティ リス トを更新する権限確認処理とをコンピュータに実 行させる。
また、 上述のチームデータリス ト保管プログラムにおいて、 前記権限確 認処理は、 前記チームマスタにより自チーム内のメンバから指名された者 であって前記サブチームの管理権限を有する一人以上のサブォ一ソリティ と、 前記サブォーソリティの持つ権限に加えて前記サブォーソリティに対 する管理権限を有する前記チームマスタとに関する情報を前記管理者情報 として用いるものであって良い。 以上説明したように、 第 4一 1〜4— 4の実施形態の発明には以下の効 果がある。
本発明では、 オーソリティ リス トとォ一ソリティデータの含まれたチー ムデータリ ス トを用いることで各チームの下にサブチームを作成すること ができ、 階層化されたチームを構築することができる。 また、 ユーザはル ―トチームのチームマスタのデジタル署名を確認するだけで、 操作対象の チームからル一トチームに至る各チームについてチームデータリス トの正 当性を確認することができる。 さらに、 親チームの管理者の指示によって 誰もがサブチーム内の管理を行うチームマスタになることができる。 また、 本発明では、 チ一ムデ一タリス トを親チームの管理下にあるォ一 ソリティデータと自チームの管理に関わるォ一ソリティ リス トに分割して おり、 各チームのチームマスタが親チームの干渉を受けることなく情報共 有メンバの管理といった自チーム内の管理を行うことができ、 一方で、 親 1 13 チームの管理者はサブチーム内部の管理に関与する必要がなくなる。
また、 本発明では、 チームデータリス トに対して正当な権限を持つ者に よるデジタル署名を含ませているため、 改竄等の不正な行為を検出するこ とが可能となる。 また、 本発明では、 チームデータリス トの操作要求が なされた場合に、 これら要求の指示者が権限を持つ者かどうかの権限確認 を実施しているので、 サーバの管理者， チーム内の一般のメンバ， クラッ 力等の権限を持たない者による不正な行為を未然に防止することができる。 また、 本発明では、 特に選定されたチームマスタと一人以上のサブォ一 ソリティに対してサブチームの管理権限を与えており、 チームマスタ自身 がサブォ一ソリティを選任できるほか、 複数の管理者がサブチームを管理 できるため管理負担が分散される。
また、 本発明では、 公開鍵などのルートチームのチームマスタ本人を識 別 ·認証するための識別情報を予め登録しておき、 この識別情報をもとに、 ル一トチームのチームマスタを確認しているため、 チームデータリストを 操作する度にユーザ自身が目視で確認するなどの煩わしい作業が必要なく なりノレ一卜チームのチームマスタを自動的に承認することが可能となる。
¾ 5— 1 a ~ 5 — 4 a , 5— 1 b〜 5— 3 b， 5— 1 c〜 5— 5 c， 第 5— l c！〜 5 _ 6 dの実施形態の発明は、 コンビュ一タネッ トワークを 利用した同報通信の分野にあって、 同報通信に利用される情報中継装置の 管理者による不正を防止できる同報通信システムに関する。
¾ 5 — 1 a〜 5— 4 a , 5 — 1 b〜 5— 3 b， 5— 1 (：〜 5— 5 c , 第 5— 1 d〜 5— 6 dの実施形態の発明に関し、 従来以下説明する技術が 知られている。
近年、 インタ—ネッ ト等のオープンなネッ トワークの普及によって、 企 114 業等の組織が持つ LAN内だけではなく、 インタ一ネッ 卜に接続されたさ まざまなメンバ一と同報通信を行うことができるようになつている。 同報 通信とは、 通信網上の多数の端末に同じ情報を一度に送信することを目的 とした通信をいい、 例えば電子メールシステムの場合には、 メ一リングリ ス トを利用することによって同報通信を実現している。 また、 他の同報通 信の例として、 リアルタイムチヤッ トなどもあげられる。 現在実現されている同報通信システムの一般的な例では、送信側端末は、 同報通信を行うメ ッセ一ジを受信者 （被配信者） の集合 （配信先リス ト） を管理する情報中継装置に転送する。 そして情報中継装置が配信するメッ セージを受信者数分複製し、 同報通信の各受信者に対して転送することに より同報通信を実現している。 例えば、 図 64に示す電子メールシステム では、 受信者の集合を示すメ一リングリス ト （L i s t O l ) を管理する メ一リングリスト管理ホス ト （S e r v e r A) に対してメッセ一ジを 送り、 このメ一リングリス ト管理ホス 卜がメーリングリストに挙げられて いる各受信者 （U s e r A, U s e r B s U s e r C) に対してメッ セージをコピーして送ることにより同報通信を実現している しかし、 前述のようなオープンなネッ トワークアーキテクチャー上に構 築された同報通信システムでは、 各受信者に配信されるメッセージの司見き 見や第三者への機密情報の漏洩等が常に問題となっていた。 このような問 題点を省みて、 今ョまで、 ED I (Electoronic Data Interchange) や E C (Electoronic commerce) のようなネッ トワーク上における機密情報 転送のニーズが高まり、 同報通信システムにおいても、 暗号技術を利用し てセキュリティを高めた同報通信システムが研究 ·開発されている。 115 喑号技術を利用してセキュリティを高めた同報通信システムとして、 特 開平 6— 1 5 2 5 9 2に開示されている同報通信システムがある。 この発 明では、 暗号化に利用するデータ鍵と受信者を特定する宛先情報とシステ ムで共通のマスタ鍵とに基づいて暗号化鍵を生成し、 この宛先情報と暗号 化鍵を通信者間で送受信することにより、 任意の一人または複数の通信相 手とデータ鍵をを共有できる暗号通信方式を開示している。 し力 し、 このシステムを利用するにあたっては、 セキュリティを確保す るために、 グループに属するメンバ一を設定しておき、 このメンバーに対 しては、 グループで喑号通信を行うために、 I Cカード等の記憶媒体を配 布しておく必要がある。 しかし、 現在利用されている同報通信 （例えば、 メ一リングリスト） においては、 グループに属するメンバ一は脱退、 加入 等により動的に変化し、 随時、 配信先が変わるため、 暗号同報通信におい ても、 このような脱退、 加入等に対応できることが望ましい。 次に、 図 6 5に示す特開平 7 - 2 4 5 6 0 5に開示されている同報通信 システムでは、 メンバーの加入 ·脱退にも柔軟に対応できる同報通信シス テムを開示されている。 この同報通信システムにおける暗号化情報中継装 置 （S e r V e r A ) は、 通信回線で接続された複数の加入者間で情報 の送受信を行うシステムにおいて、 発信加入者から送信され受信した喑 号化情報の復号化（②）、 または、受信加入者に送信する情報の暗号化（③） を行なう暗号計算部と、 暗号化情報を複号化するための共通秘密鍵と、 各加入者 （U s e r A , U s e r B , U s e r C ) に対応した暗号化 を行うための各加入者毎の個別公開鍵とを格納した鍵格納部とを有する喑 号化情報中継装置をもつ。 1 16 しかし、 この情報中継装置の管理者、 もしくは、 この管理者によって権 限を委譲された者は、 たとえ同報通信の加入者の中に含まれていない場合 でも、 暗号通信の通信内容を司見き見することができる。 よって、 悪意ある 情報中継装置の管理者が存在する場合には、 暗号通信で転送される機密情 報が漏洩する危険性がある。 例えば、 企業間で行う同報通信での機密情報 として企業の合併情報などが挙げられるが、 これは、 合併の影響を受ける 情報中継装置の管理者に漏洩してはいけない情報である。
また、 この情報中継装置は、 必ず、 暗号化情報の復号化処理、 暗号化処 理を行うことになる。 しかし、 暗号化処理 ·複号化処理は複雑で、 大きな 処理能力を必要とする。 よって、 同時に多数の暗号化情報が情報中継装置 に到着した場合には、 同報通信の遅延や、 情報中継装置の処理能力を超え たために、 動作不能に陥る危険性がある。 企業や組織、個人等が漏洩すると大きな損害を被るであろう機密情報を、 限定された複数のメンバ一間だけで同報通信を行うためには、 以下のよう な課題を解決した同報通信システムを実現する必要がある。
( 1 ) 情報中継装置の管理者といえども、 同報暗号通信の通信内容は、 司見き見できない仕組みを実現し、 本当に情報を共有する必要のあるメンバ —にだけ同報通信内容が見られるようにする。
( 2 ) 同報通信を行う受信者の脱退や、 加入に対して迅速に対応でき、 同報通信メンバ一の動的な変更があっても、 誤って同報通信してはいけな いメンバ一に情報を転送してしまうことを防止できるようにする。
( 3 ) サーバ管理者が同報通信の配信メンバーを管理するのではなく、 同報通信を行うメンバーの中で配信メンバ一を管理し、 さらにメンバ一の 管理者に集中する管理負担をできるだけ軽減する。
( 4 ) 機密情報を転送するため、 多数の受信者それぞれが、 確実に受信 117 できる仕組みを確立する。 第 5 — 1 a ~ 5— 4 a , 第 5 — 1 b〜 5— 3 b , 5 — 1 c〜5— 5 c， 第 5— l d〜 5— 6 dの実施形態の発明は、 上記の点に鑑みてなされたも ので、 上記課題を解決する同報通信システムを構成するメンバ一リスト管 理装置、 暗号情報作成装置、 情報中継装置、 暗号情報複号化装置、 および、 こららをコンピュータに実現させるプログラムを記録した記録媒体を提供 するものである。 まず、 第 5— l a〜5— 4 a , 第 5— l b〜 5 — 3 b， 第 5— l c〜5 - 5 c , 第 5— l c！〜 5 — 6 dの実施形態の発明の同報通信システムを構 成するメンバーリス ト管理装置、 暗号情報作成装置、 情報中継装置、 暗号 情報復号化装置の各実施の形態の説明にあたり、 本発明の基本的技術思想 および実施の形態の説明に用いる用語を説明する。 図 5 2に本発明の同報 通信システムの概要を示している。 なお、 本発明の同報通信システムを構 成する各装置の実施の形態は後ほど詳細に説明する。 上述したように、 従来の同報通信では、 情報中継装置 （サーバ） に保存 された被配信メンバ一 （受信者） の設定は、 主にサーバ管理者、 もしくは、 サーバ管理者によって権限を委譲された者によって管理されていた。 しか し、 機密情報を同報通信する場合には、 サーバ管理者が管理すべきでない 同報通信を行う可能性がある。 そこで本発明では、 サーバ管理者ではなく、 同報通信メンバー内のメン バ一を管理する管理者 （以降、 チームマスターと称す） による被配信メン バーのリス ト （以降、 メンバ一リス トと称す） の管理を実現し、 このメン 118 バ一リス 卜が他者に改竄されない仕組みを提供する。 そして、 メンバーリ ス卜が安全かつ確実にメンバーリス トに含まれるメンバーで共有され、 メ ンバーが発信する同報通信の情報内容は暗号化され、 情報が漏洩すること なく、 同報通信メンバーが安全かつ確実に機密情報を受信できるようにす るものである。 まず、 機密情報を安全かつ確実に同報通信をするには、 通信相手となる メンバー本人を識別 ·認証する仕組みが必要となる。 本発明では、 本人を 識別するための手法として、 公開鍵暗号方式 （例えば、 R S A (Rivest- Shamir-Adleman) 方式や楕円喑号方式） における秘密鍵が、 本人のみに よって所有される仕組みを利用する。 そのため、 本発明のメンバーリ ス ト には、 少なく とも、 秘密鍵に対応する公開鍵が含まれる。 また、 メンバ一 リストが安全に管理されるようにするため、 他者によって改竄されない仕 組みを実現するため、 チームマスターによるデジタル署名を添付する。 メンバ一リス トは、 一般的には、 チームマスタ一によって管理されるが、 例えば、 同報通信のメンバ一の数が多く、 一人の管理者で管理できない場 合には、 メンバ一リス トを複数のリス トにわけ、 チームマスタ一リス トに 含まれる複数の管理者 （チームマスタ一と、 チームマスタ一から権限を与 えられたサブマスタ一） によって、 管理される場合がある。 図 5 3に示す ように、 一般的なメンバ一リス トは、 チーム名、 チームマスタ一であるメ ンバ一 Xの名前もしくは識別子と、 チームのメンバーであるメンバー Y、 · · '、 メンバ一 Βの名前も しくは識別子と、 このメンバ一リス トに対するチ —ムマスタ一 Xのデジタル署名からなる。 また図 5 4に、 前述したように メンバーリス 卜が複数のリス トからなる場合、 特にメンバーリ ス トをチ一 ム 1 0 1 ί の管理者を登録したチームマスタ一リス トと、 チーム 1 0 1 Ε 119 の同報通信メンバ一を登録したメンバ一リス 卜に分割した場合の例を示し ている。 この例のメンバ一リス トのデジタル署名は、 チームマスタ一の X のみならず、 サブマスタ一の Υ、 Ζのデジタル署名であってもメンバ一リ ストの正当性を確認できる。 この場合には、 まず、 メンバーリス トのデジタル署名より、 メンバ一リ ストが改竄されていないかを検証し、 デジタル署名者 （この例では、 メン バ一 X ) を特定する。 次に、 チームマスタ一リス トのデジタル署名より、 チ一ムマスタ一リス トが改竄されていないかを検証し、 さらにチームマス ターのデジタル署名者が間違いなく このチームのチームマスタ一かどうか を確認する。 最後にこのメンバ一リス トのデジタル署名者が、 チームマス タ一リス トにチームの管理者として登録されているかを検証する。 図 5 4 の例では、 メンバ一 Xは、 チームマスタ一として登録されているので、 正 当なデジタル署名者であると判断できる。 また、 メンバーリス トにメンバ —Υによるデジタル署名が添付されていた場合でも、 メンバ一 Υは、 メン バ一Xより管理権限を委譲された正当なデジタル署名者 （ここでは、 サブ マスタ一とする一図 5 4中では、 「サブ」 と記載している） と して判断で きるため、 正当性を検証できる。 また、 メンバ一リストには、 一人のメンバ一に対して、 複数の公開鍵を 登録する方式としてもよい。 例えば、 暗号化 ·複号化処理に利用する公開 鍵と秘密鍵のペアと、 デジタル署名作成 ·検証処理に利用する公開鍵と秘 密鍵のペアを、 それぞれ異なる鍵ペアを利用する場合には、 各メンバーに 対して 2つの公開鍵が登録されていることになる。 また、 メンバーリス トには公開鍵を登録するが、 この公開鍵として認証 120 局より発行されたデジタル証明書 （例えば、 X . 5 0 9フォーマッ トに従 つたデジタル証明書であり、 以降、 証明書と称す） を利用することができ る。 また、 メ ンバーリス トに、 公開鍵本体を一意に識別するための情報を 登録する方式を利用してもよい。 この場合は、 公開鍵本体は、 各メ ンバ一 がすでに保有している場合には、 公開鍵を識別する情報 （例えば、 信頼で きる認証局より発行された証明書に含まれる公開鍵を利用している場合に は、 その証明書に与えられたシリアル N oや認証局名、 証明書をハッシュ 関数で圧縮したメッセージダイジェス ト） をメンバ一リス トに含めておけ ば、 各メンバーは、 メンバ一リス トを受け取った後、 暗号化に利用する実 際の公開鍵本体を選択もしくは、 取得することができる。 例えば、 メ ンバ —リス トに認証局名とシリアル N oが含まれていた場合には、 まず、 端末 に接続された記憶媒体に保存された複数の証明書から、 この認証局名とシ リアル N oをもつ証明書を検索し、 記憶媒体に存在しなかった場合には、 この認証局名の認証局に問い合せこのシリアル N oの証明書を取得するこ ともできる。 以下に、 第 5— l a〜5 — 4 a , 第 5— l b〜5— 3 b， 第 5— l c〜 5 - 5 c , 第 5— l c！〜 5— 6 dの実施形態の発明の同報通信システムを 構成するメ ンバ一リ ス ト管理装置、 暗号情報作成装置、 情報中継装置、 喑 号情報復号化装置の各実施の形態を図面を参照し順に説明する。 図 5 5は、 本発明のメンバ一リス ト管理装置の第 5— 1 aから第 5— 4 aの実施の形態を包含し表している。
[第 5— 1 aの実施形態]
まず、 メンバ一リ ス 卜管理装置 1 ί の第 5 — 1 aの実施の形態を説明す 121 る。 本実施の形態は、 メ ンバ一リス トを管理するために、 同報通信を行う 1以上のメンバーの公開鍵を含むメンバ一リス トを作成するリスト作成部 1 a ί と、 メンバーリス トに含める公開鍵を取得し保存する公開鍵管理部 1 b £ とから構成される。 はじめにチームマスタ一が、 メンバ一リス ト管理装置 1 f を利用してメ ンバ一リス トを作成するための所定の項目 （メ ンバーの情報等） を入力す る。 データの入力後、 図 5 6に示すようにリ ス ト作成部 1 a ίは、 メンバ —として登録するメンバーの公開鍵を選択する （ステップ S 1 ί )。 例え ば、 図 5 3に示すメ ンバ一リス トを作成する場合、 メ ンバー X、 Υ、 · · ·、 Βの公開鍵が選択される。 そして、 ハッシュ関数 （例えば、 M D 5 S H A - 1等） を利用してメンバ一リス トのメッセ一ジダイジエス トを作成す る （ステップ S 2 £ )。 そして、 作成したメッセ一ジダイジエス トをチ一 ムマスターの秘密鍵で暗号化して （例えば、 R S Aや D S Aを利用して） 作成したデジタル署名をメ ンバーリ ス トに添付 （ステップ S 3 ε ； 図 2の 例では、 Xのデジタル署名を添付） する仕組みとする。 この仕組みにより、 後述の情報中継装置以外の端末 （図示せず） をメ ンバーリス ト管理装置 1 f として利用しても、 メ ンバ一リ ス トを改竄される心配はない。 現実に改 竄された場合には、 メンバーリス トの正当性を検証することにより改竄が 発覚するため、 改竄されたメンバ一リス 卜の使用を中止することが可能で ある。
[第 5— 2 aの実施形態]
次に、 メンバーリス ト管理装置 1 f の第 5— 2 aの実施の形態として、 第 5 _ 1 aの実施の形態のメンバ一リス ト管理装置 1 "こ、 さらにリス ト 取得保存部 1 c t を備えた構成をとる。 122 リスト取得保存部 1 c f は、 メンバーリス ト管理装置 1 f に接続された 記憶媒体に対するメンバーリス トの取得保存を行なうように動作するだけ でなく、 メンバーリス ト管理装置 1 f が接続されたネッ トワークに配置さ れた端末 （例えば、 サーバ） やデータベース （図示せず） を利用して、 こ れらの端末やデータベースにアクセスし、 メンバーリス トを取得または保 存するように動作する。
この構成をとるのは、 あるチームマスターがメンバーリス トを管理して いる間に、 チームマスタ一の端末に障害が発生した場合や、 誤ってメンバ —リス 卜が消去される危険性があるため、 チームマスターの端末でなく、 ネッ トワーク上の安全な端末 （例えば、 サーバ） またはデータベースにメ ンバ一リス トを保存しておく と、 より安全であるからである。 また、 同報通信の管理負担が一人の管理者に集中すること軽減し、 操作 ミス等を未然に防止するため、 複数の管理者 （チームマスタ一と複数のサ ブマスタ一） でメンバ一リストを管理する形態もある。 この場合、 各管理 者が異なるパージヨンのメンバ一リス トを利用することが無いように、 各 管理者がアクセスできるネッ トワーク上の端末またはデータベースに、 メ ：—リス トを保存する方がより完全性を保った同報通信を実現できる。 本発明の同報通信システムは、 メンバ一リス トに含まれる公開鍵によつ て暗号化を行うことによって、 同報通信メンバ一外への情報の漏洩を防ぐ
(例えば、 サーバ管理者への情報の漏洩を防ぐ） 仕組みを実現している。 よって、 メンバ一リス ト管理装置 1 f では、 メンバ一リストが正当性をも つて管理されているかを検証する必要がある。 ここでいう正当性の検証と は、 1 ) メンバ一リス ト力 権利のない者に改竄されていない状態を維持 している、 かつ、 2 ) メンバーリス トを作成した者が同報通信を行うチー 123 ムの正式なチームマスタ一である、 状態を確認することである。
1 ) については、例えば、 メンパーリス 卜に添付されたデジタル署名 （図 5 3の例では、 メンバ一 Xのデジタル署名） を複号化してメンバ一リス ト のメッセ一ジダイジェス トを取得し、 さらに、 メンバ一リス ト （図 5 3の 例では、 チーム 1 0 1 ε 、 メンバ一 X、 メンバ一 Υ…メ ンバー Βを内容と してもつリスト） をメンパーリス ト作成時に用いられたものと同じハツシ ュ関数で圧縮して得たメッセ一ジダイジエス トを取得し、 双方を比較する ことにより検証できる。 また、 2 ) については、 例えば、 メ ンバーリス ト へのデジタル署名者の名前 （例えば、 X . 5 0 9の証明書フォーマツ 卜に 従う証明書に記載された名前） をメ ンバーリ ス ト利用者が確認できるよう に画面に表示し、 確認してもらうことにより検証できる。 リス ト取得保存部 1 c f は、 メンバーリス トを識別する情報とメンバ一 リス トを管理するチームマスタ一を対応づける対応テ一ブルを作成し保存 する機能と、 メンバ一リ ス 卜に添付されたデジタル署名の正当性を確認す る際に、 この対応テ一ブルを参照して、 デジタル署名が正当なチームマス ター本人のデジタル署名であるかどうかを判断させる機能をさらに備える ことでメンバーリス トの正当性を検証できる。
また、 対応テーブルを作成するにあたっては、 例えば、 初めて取得する メンバ一リス トの場合には、 メンバ一リス ト利用者がチームマスタ一を確 認できるように画面に表示し、 確認してもらうことにより検証する。 ここ で肯定指示 （メンパーリス 卜のデジタル署名者としてこのチームマスタ一 を認める場合） が出た場合には、 メンバ一リス トを識別する情報 （図 5 3 の例では、 チーム名の 「チーム 1 0 1 ί 」） とメンバ一リス トを管理する チームマスタ一 （図 5 3の例では、 チームマスターである 「メ ンバ一 Χ」） 124 を、 テーブルに追加する追加機能をさらに備えることで、 2回目以降は、 自動的に正当性確認が行われるようになる。
ここで説明した、 メンバーリ ス トの正当性を検証する機能は、 後述の喑 号情報作成装置、 暗号情報復号化装置、 情報中継装置のそれぞれにおいて も備えられ、 メンバ一リス トの取得時もしくはメンパーリス トを利用する 際に機能する。
[第 5 — 3 aの実施形態]
次に、 メ ンバーリ ス ト管理装置 1 £ の第 5— 3 aの実施の形態として、 第 5— 1 aもしくは第 5— 2 aの実施の形態のメンバーリス ト管理装置 1 ε に、 リス ト送信部 1 d f をさらに備えた構成をとる。
リス ト送信部 1 d f は、 メンバ一リス トに含まれるメンバーが利用する 端末にメンパーリス トを送信するように動作する。
この構成をとることにより、 最新のメンバーリス トをメンバ一リス トの メンバ一間で迅速かつ正確に共有することができる。 また、 チームマスターはさらに、 後述する情報中継装置が情報を再配信 する際に参照する配信先リス トを変更する必要がある。 この配信先リスト を変更する仕組みは、情報中継装置の種類や仕組みによって異なってくる。 例えば、 音声チヤッ トの同報通信システムとメールの同報通信システムで は、 装置の構造やプロ トコルが異なる。 本実施の形態のメンバ一リスト管 理装置 1 f では、 利用するシステムによって操作方法が異なることの無い ように、 メンバ一リス 卜に含まれるメンバ一と配信先リス トに含まれるメ ンバ一が同一になるように、 メンバーリス ト管理装置 1 f に配信先リス ト を変更する機能をさらに付加してもよい。 この配信先リ ストを変更する機 能として、 もっとも簡単な実施形態としては、 本実施の形態のリス ト送信 125 部 1 d Eからメンバーリス トを情報中継装置に転送し、 情報中継装置では このメンバーリス トを配信リス 卜として用いる方式があげられる。
[第 5 — 4 aの実施形態]
本発明のメンバ一リス ト管理装置の第 5— 4 aの実施の形態として、 第 5 - 1 aないし第 5— 3 aのいずれかの実施の形態のメンバーリス ト管理 装置 1 f に、 加入要求受付部 1 e £ をさらに備えた構成をとる。
加入要求受付部 1 e f は、 同報通信のメンバーリス 卜への加入要求を受 け付けるために、 同報通信のチームマスタ一が、 特定同報通信の配信リス トへの加入要求項目を設定する加入要求項目設定機能と、 加入要求を受付 ける際に加入要求者が満たすべき項目を提示するための加入要求項目提示 機能と、 加入要求者が転送してきた加入要求が、 加入要求項目を満たし、 加入を許可するか否かをを判断する加入許可判断機能を備える。
また、 本実施の形態の加入要求受付部 1 e ∑ は、 加入要求が正確な要求 であるかどうかを検証する際に、 ネッ トワーク上に配置されたデータべ一 スゃサーバ等に、 問い合わせて検証を行なう。 例えば、 加入項目にクレジ ッ トカ一ド Ν οが記載されていた場合には、 このクレジッ トカ一ド Ν οの 有効性をクレジッ トカ一ド会社が運用する端末にアクセスして検証したり、 証明書が含まれて 、た場合には、 認証局が運用する証明書データベースに アクセスして検証することができる。
上述の加入要求受付部 1 e £ の機能により、 同報通信への受信者の自動 加入を実現することができる。 現在実現されている同報通信への受信者の 自動加入の一例として、 例えば、 メ一リングリス トへの加入プロセスを自 動化し、 ユーザが WWWページで登録するとメ一リングリス トに自動的に 126 加入できるシステムがある。 しかし、 現在のメーリングリス トは、 情報中 継装置の管理者の権限で起動されるプロセスを自動化したものであり、 現 在の自動化プロセスでは、 情報中継装置の管理者が、 配信メンバ一を自由 に設定できる仕組みを提供しているにすぎない。 本実施の形態の加入要求 受付部 1 e ε は、悪意ある情報中継装置の管理者などによる不正を防止し、 より安全性の高い自動加入の仕組みを提供するためのものである。 ここで、 メンバ一リス トに含まれる公開鍵や、 秘密鍵は、 間違いなく本 人のものかどう力、 また、 使用期限などを設定していた場合に期限切れで ないか、 また、 すでに秘密鍵が漏洩していないかを検証してから利用する 方が望ましい。 したがって、 メンバ一リス ト管理装置 1 f の各実施の形態 では、 ネッ トワーク上に配置されたデータベース （例えば、 認証局ゃサー ビス企業が提供する公開鍵の有効性や信頼性をあらわす状態を登録したデ ィレク トリデータベースなど） に、 同報通信と同じまたは、 異なるプロ ト コル （例えば、 同報通信で S M T P (Simple Mail Transfer Protocol) を 利用する場合には、 L D A P (Lightweight Directory Access Protocol) , 〇 C S P (Online Certificate Status Protocol) など） を利用して問い合 わせを行ったり、 認証局よ り配布される証明書廃棄リ ス ト （ C R L (Certificate Revocation List) ) を利用して、 公開鍵やデジタル署名に利 用される秘密鍵の有効性を検証する形態としてもよい。
ここで説明した、 公開鍵やデジタル署名に利用される秘密鍵の有効性を 検証する機能は、 後述の暗号情報作成装置、 情報中継装置、 暗号情報復号 化装置のそれぞれにおいてもこの機能を備えることにより、 デジタル署名 の確認ゃメンバ一リス 卜の管理の際に有効となる。
以上、 本発明のメンバーリス ト管理装置の各実施の形態を説明した。 127 次に、 本発明の暗号情報作成装置の実施の形態を説明する。 図 5 7は、 本発明の暗号情報作成装置の第 5— 1 bから第 5 - 3 bの実施の形態を包 含し表している。
[第 5— 1 bの実施形態]
本発明の暗号情報作成装置の第 5— 1 bの実施の形態は、 ネットワーク を介してメンバ一リス トを取得し保存するリス ト取得保存部 2 a f と、 喑 号情報を作成する暗号化部 2 b ί とから構成される。 リス ト取得保存部 2 a £ は、 ネッ トワーク上に配置されたリ ソ一スデー タベースに保存されたメンバーリス トを、 同報通信と同じ、 または、 異な るプロ トコル （例えば、 同報通信で S M T Pを利用する場合には、 H T T Pなど） を利用して取得する。 または、 転送されてきたメンバーリス トを 記憶装置 （図示せず） に保存し、 必要なときに保存先からメンバ一リス ト を読み込むことにより取得する。 また、 暗号情報作成装置 2 I がすでにメンバーリス トを保存している場 合には、 リス ト取得保存部 2 a £ は、 メンバーリス トが最新バージョ ンか 確認するように動作する。 例えば、 メンバーリス トの最新バージョンに関 する情報が保存されたネッ トワーク上に配置されたデータベースに、 同報 通信と同じまたは、 異なるプロ トコル （例えば、 同報通信で S M T Pを利 用す場合には、 L D A P、 O C S Pなど） を利用して、 最新のメンバ一リ ス トのバージョンを問い合わせ確認する。 また、 リス ト取得保存部 2 a ί は、 前述のメンバ一リス ト管理装置 1 ίの実施の形態で説明したメ リス トの正当性を検証する機能を備え、 メンバーリス 卜の取得時にメ —リス 卜の正当性を検証する。 128 なお、 記憶部 （図示せず） は、 E E P R O M、 ハードディスク、 光磁気 ディスク等の不揮発性の記憶装置により構成されている。 次に、 暗号化部 2 b £ は、 図 5 8に示すようにまず同報通信文 （平文） とリス ト取得保存部 2 a £ により取得されたメンバーリストを取得し、 同 報通信文を共通鍵暗号方式 （例えば、 D E S等の暗号化と複号化で同じ鍵 を利用する暗号方式） で暗号化し暗号文を作成する。
そして暗号文作成に用いた共通鍵を、 メンバ一リス トに含まれる各メン バ一公開鍵を用いて、 公開鍵暗号方式 （例えば、 R S A方式） により暗号 化した暗号化鍵を作成する。 このときメンバ一が 3名ならば、 3つの暗号 化鍵が作成されることになる。
さらに複数の暗号化鍵のうち、 被配信メンバーに対応する暗号化鍵を選 択するための鍵選択情報を作成する。 この鍵選択情報として、 例えば、 メ ンバ一名と暗号化鍵を対応させるテーブルを用いてもよい。
また、 同報通信文をハッシュ関数で圧縮し、 送信者の秘密鍵で暗号化し たデジタル署名を付加する。 このデジタル署名により改竄防止、 送信者の 確認ができるようになる。
そして暗号情報と して、 暗号文、 暗号化鍵、 鍵選択情報、 およびデジタ ル署名を出力するように動作する。
なお、 同報通信システムにおいて、 この暗号情報作成装置 2 £は送信側 端末で利用されるものである。
[第 5— 2 bの実施形態]
次に、 暗号情報作成装置 2 £ の第 5— 2 bの実施の形態は、 図 5 7に示 すように第 5— 1 bの実施の形態に宛先検査部 2 c £ をさらに備える構成 をとる。 129 宛先検査部 2 c ∑ は同報通信文の送信先を検査し、 情報中継装置が送信 先となっていて、 かつ、 同報通信に利用するメンバ一リス トが取得できる 場合にのみ、 同報通信文を暗号化部 2 b ί へ渡すように動作する。
この宛先検査部 2 c f を設けることで、 暗号情報作成装置 2 f は暗号化 処理だけを行うように実施でき、 したがって同報通信文自体の作成は、 汎 用的なメッセージ作成装置 （ワードプロセッサーや、 メ一ラ一、 チャッ ト クライアント等） を利用できる。 例えば、 暗号情報作成装置 2 £ をメ一ラーのプラグィン · ソフ トとして 実現した場合、 メールの文章および添付ファイルの作成までは、 既存のメ 一ラーの機能を利用できる。 暗号情報作成装置 2 E としてのプラグイン · ソフ トは、 メール送信前に宛先を検査し、 メーリングリス ト ·サーバのァ ドレスが宛先となっていた場合には、 このァ ドレスに対応するメンバ一リ ストを取得し、 メンバ一リス トに含まれる公開鍵を利用して上述の暗号化 を行い暗号情報を作成する。 この暗号情報は、 既存のメールが利用する通 信機能 （例えば、 プロ トコルとして S M T Pを利用した通信機能） を利用 して、 メーリングリス ト ' サーバへと送信される。
なお、 本実施の形態の暗号情報作成装置 2 ί に、 同報通信文を作成する 専用の同報通信情報作成部 （図示せず） をさらに備えてもよい。
[第 5— 3 bの実施形態]
次に、 暗号情報作成装置 2 £ の第 5— 3 bの実施の形態は、 図 5 7に示 すように第 5— 1 bまたは第 5— 2 bの実施の形態に複数パーツ送信部 2 d ί をさらに備える構成をとる。
本実施の形態では、 暗号化部 2 b f は、 同報通信文が複数のパーツで構 成されている場合には、 個々のバ一ッごとに前述の暗号化処理を行い暗号 130 情報を作成する。 そして、 複数パーツ送信部 2 d ί は、 図 5 9に示すよう に同報通信文が複数のパーッで構成されている場合、 情報中継装置の受信 能力に応じてパーツのうちのいくつかを情報中継装置から参照できる情報 保管装置 5 f に送信するように動作する。 この際、 各パーツの送信に最適 なプロ トコルを用いることができる。 例えば、 音声チャッ トには、 リアル タイム通信プロ トコル、 ファイルの転送には、 ファイル転送プロ トコルを 利用する。 なお、 複数パーツ送信部 2 d f は、 ネッ トワーク上に配置されたリ ソー スデータベースまたは、 情報中継装置 4 ί に問い合わせることで、 情報中 継装置 4 £から参照でき同報通信文の一部を転送しても良い情報保管装置 5を知る。 また、 別の方法として、 メンバ一リ ス トに情報保管装置 5 f の ァ ドレスを含め利用してもよい。
また、 複数パーツを別々の装置に送信する場合には、 受信者は、 もとの 情報が全部揃ったかどうかを検証する必要がある場合がある。 その場合に は、それぞれの暗号化処理を行なった際に、 もとの全平文パーツもしくは、 全暗号文パーツもしくは、 各平文パーツのメッセージダイジヱス 卜の集合 もしくは、 各暗号文パーツのメッセージダイジエス 卜の集合のうち一つも しくは、 いくつかを組み合わせた情報に対してハッシュ関数を利用して作 成したメッセージダイジエストもしくは、 このメッセージダイジエストに デジタル署名したものを添付することにより、 各情報をまったく異なる装 置に転送した場合でも、同報通信文全体の完全性を検証することができる。 本実施の形態では、 各パーツの複数のプロ トコルにまたがる通信となつ ても、 情報の暗号化処理およびメンバ一リス トは同一のものを利用し、 確 実にチームマスタ一が設定したメ ンバ一間での同報通信が行え、 各パーツ 131 の同報通信の安全性、 確実性のレベルを等しくすることができる。 本実施の形態は、 同報喑号通信システムにおいて、 異なるフォーマッ ト のメッセージを同時に同報通信する場合に有効である。 例えば、 音声チヤ ッ ト同報通信システムを利用して、 複数の企業にまたがるメンバ一が商談 を行いながら、 同時に、 契約書ファイルを転送する場合や、 メ一リングリ スト同報通信システムを利用して、 メンバーに対して喑号メ一ルを送信す るとともに、 メールシステムの許容量を超えるような大きなファイル （例 えば、 5 M b y t eの画像ファイル） を転送する場合がある。 例えば、 音 声チャッ トの場合には、 契約書ファイルを転送しょうとした時点で、 音声 チヤッ 卜の音声が途切れてしまい同報通信が不通となるようでは、 重要な 機密情報を取り扱っている場合には、 聞き落とし等が発生する危険性があ る。 また、 メーリングリス 卜同報通信装置では、 それぞれの受信側メ一ルシ ステムの設定によって許容量 （例えば、 メンバー Aのシステムでは、 3 M b y t e , メンバ一 Β ί のメールシステムでは、 1 M b y t e ) が異なる 上、 特定メンバ一用に確保されたメール受信用のバッファにどの程度空き 容量あるかによって、 受信能力が異なるため、 送信者は、 確実に送信でき るか想定しがたい。 本実施の形態は、 これらの環境においても有効に機能 するものである。 また、 暗号化時に利用するメンバーリス トに含まれる公開鍵は、 暗号化 に利用する前に有効性を検証する方がより、 セキュリティの安全性が向上 する。 例えば、 チームマスタ一がメンバ一リス トを作成した時点では、 す ベての公開鍵が有効であっても、 一定期間後同じ鍵を使おうとしても、 使 132 用期限を迎えた鍵が存在したり、 秘密鍵が漏洩している可能性がある。 喑 号情報作成装置 2 f の各実施の形態では、 メンバーリス ト管理装置 1 f の 公開鍵やデジタル署名に利用される秘密鍵の有効性を検証する機能と同様 の鍵有効性検証機能を備えることによりさらに安全性が向上する。
以上、 本発明の暗号情報作成装置の各実施の形態を説明した。 次に、本発明の暗号情報復号化装置の実施の形態を説明する。図 6 0は、 本発明の暗号情報復号化装置の第 5— l cから第 5— 5 cの実施の形態を 包含し表している。
[第 5— 1 cの実施形態]
暗号情報複号化装置 3 f の第 5— 1 cの実施の形態は、 後述する情報中 継装置から転送されてきた暗号情報を取得する暗号情報取得部 3 a f と、 暗号情報を復号化する複号化部 3 b f とから構成される。
複号化部 3 b £ は、 図 5 8に示すようにまず暗号情報に含まれる鍵選択 情報を参照しメンバ一数に相当する複数の暗号化鍵の中から復号化に使用 する暗号化鍵を選択する。 そして暗号化鍵を公開鍵暗号方式を利用して受 信者の秘密鍵を用いて複号化し共通鍵を得る。 そして、 共通鍵暗号方式を 利用して、 共通鍵を使用し暗号情報に含まれる暗号文を複号化し、 平文の 同報通信文を得る。 そして、 デジタル署名を送信者の公開鍵で復号化たメ ッセ一ジダイジエス ト M D f と、 暗号文を復号化した同報通信文 （平文） をハッシュ関数で圧縮したメッセージダイジェス ト M D ' ί を比較 ·検証 し、 改竄や送信者の確認を行なう。
[第 5— 2 cの実施形態]
次に、 暗号情報復号化装置 3 f の第 5 — 2 cの実施の形態として、 図 6 133
0に示すように第 5— 1 cの実施の形態の暗号情報復号化装置に、 さらに 受信者本人が受信したことを確認するための受信通知を情報中継装置に発 信する受信通知発信部 3 c f を備える構成をとる。 受信通知発信部 3 c £ は、 例えば、 受信した通信内容のメッセージダイジェス トと受信した時間 のタイムスタンプ、 受信者の I D等に対してデジタル署名を添付した受信 通知を発信する。 この構成をとるのは、 例えば、 受信側の端末が故障していたり、 通信回 線が不通となっていた場合には、 通信内容が受信者に着信しない可能性が ある。 そのため、 受信者は受信通知を発信することが望ましい。 しかし、 従来の受信通知 （例えば、 Eメールの開封通知） では、 途中で悪意ある者 が、 成りすまして同様の通知を送ることが可能となるため、 安全な受信通 知とは言えない。 本実施の形態の暗号情報複号化装置 3 tは、 上記受信通 知発信部 3 c εを設けている。 これにより機密情報を送受する同報通信に おいて、 受信者本人がデジタル署名を添付した受信通知を情報中継装置に 発信することができ、 情報中継装置ではこのデジタル署名を検証すること により、 メンバ一リストに登録されたメンバ一の 1人に確実に配信できた ことを確認できる。
[第 5— 3 cの実施形態]
次に、 暗号情報復号化装置 3 f の第 5— 3 cの実施の形態として、 図 6 0に示すように第 5— 1 cまたは第 5— 2 cの実施の形態の暗号情報復号 化装置に、 さらに複数パーツ受信部 3 d £ を備える構成をとる。
複数パーツ受信部 3 d ί は、図 5 9に示すように同報通信文の内容より、 情報保管装置 5 £ にパーツの一部分が転送されているか判断し、 もし、 パ —ッが転送されている場合、 情報保管装置 5 f に問い合わせ、 各パーツの 134 送信に最適なプロ トコル （例えば、 H T T Pプロ トコルゃ F T Pプロ トコ ル） を利用してパーツを取得する。 また、 本実施の形態の復号化部 3 b ε は、 暗号化情報が複数のパーツで構成されている場合には、 個々のパーツ ごとに複号化処理を行うように動作する。
なお本実施の形態は、 同報通信文が複数のパーツで構成され、 前述の喑 号情報作成装置 2 ε により、 パーツのうちのいくつかが情報中継装置 4 ε から参照できる情報保管装置 4 ί に送信される場合に対応するものである。
[第 5— 4 cの実施形態]
本発明の暗号情報復号化装置の第 5— 4 cの実施の形態は、 図 6 0に示 すように第 5— 1 cないし第 5 — 3 cの実施の形態のいずれかの暗号情報 復号化装置 3 ε に、 さらに同報通信安全性検証部 3 e ί を備える構成をと る。
同報通信安全性検証部 3 e ί は、 その機能の 1つとして送信者がメンバ 一リス 卜に登録されているメンバーかどうかを検証するように動作する。 この検証の際には、 後述のリス ト取得保存部 3 f f よりメンバーリス トを 取得して送信者を確認する。 また、 ネッ トワーク上に配置されたメンバ一 リス トに関する情報を登録したリソースデータベースにアクセスし （例え ば L D A Pなどのプトロコル） を利用して、 メンバーリストの中に含まれ ている送信者かどうかを、 問い合わせるようにしてもよい。 また、 後述の 情報中継装置に備わる同報通信安全性検証部と同様の機能をさらに備えて もよい。
[第 5— 5 cの実施形態]
本発明の暗号情報復号化装置の第 5— 5 cの実施の形態は、 図 6 0に示 すように第 5— 1 cないし第 5— 4 cの実施の形態のいずれかの暗号情報 135 複号化装置 3 f に、 さらにリス ト取得保存部 3 f t を備える構成をとる。 リスト取得保存部 3 f f は、 メンパーリス トをネッ トヮ一ク上に配置さ れたリソースデータベースに保存されたメンバ一リス トを、 同報通信と同 じ、 または、 異なるプロ トコル （例えば、 同報通信で S M T Pを利用する 場合には、 H T T Pなど） を利用して取得する。 もしくは、 転送されてき たメンバーリス トを記憶装置 （図示せず） に保存し、 必要なときに保存先 からメンパーリス トを読み込むことにより取得する。
また、 暗号情報復号化装置 3 £がすでにメンバーリ ス トを保存している 場合には、 リス ト取得保存部 3 f f は、 メンバーリス トが最新バージョン か確認するように動作する。 例えば、 メンバ一リス トの最新バージョンに 関する情報が保存されたネッ トヮ一ク上に配置されたデータベースに、 同 報通信と同じまたは、 異なるプロ トコル （例えば、 同報通信で S M T Pを 利用す場合には、 L D A P、 O C S Pなど） を利用して、 最新のメンバ一 リス 卜のバージョンを問い合わせ確認する。 また、 リス ト取得保存部 3 f £ は、 前述のメンバーリス ト管理装置 1 E の実施の形態で説明したメンバーリス 卜の正当性を検証する機能を備え、 メンバ一リス 卜の取得時にメンバ一リス 卜の正当性を検証する。
さらに、 前述の暗号情報作成装置の実施の形態で説明した公開鍵やデジ タル署名に利用される秘密鍵の有効性を検証する機能を、復号化部 3 b E 、 リス ト取得保存部 3 f ∑ に備え利用する形態としてもよい。 これらの機能 をさらに備えることで、 安全性がさらに向上する。
以上、 本発明の暗号情報複号化装置の各実施の形態を説明した。 図 6 1は、 本発明の情報中継装置の第 5— 1 d力ゝら第 5— 6 dの実施の 136 形態を包含し表している。
[第 5— 1 dの実施形態]
まず、 本発明の情報中継装置の第 5— 1 dの実施の形態を説明する。 本実施の形態は、 チームマスターによって管理される配信先リストを保 存 ·管理する配信先リス ト管理部 4 a ε と、 転送されてきた暗号情報を、 配信先リス トに含まれる被配信メンバーに転送するために複製する情報複 製部 4 b f と、 複製された暗号情報をそれぞれの被配信メンバーに送信す る送信部 4 c £ とから構成される。 配信先リス ト管理部 4 a ∑は、 配信リストを保存■管理する機能と、 メ ンバ一リストを取得し保存する機能と、 メンバーリス トを取得する際に、 メンパーリスト管理装置の実施の形態で説明したメンバーリス 卜の正当性 を検証する機能と、 メンパーリス トと配信リストに含まれるメンバ一を一 致させる機能を備える。 なお、 配信先リスト管理部 4 a ίがメンバ一リス トを参照して配信先リス トを設定する場合には、 メンパーリス トが最新バ 一ジョンであるか確認する機能をさらに備える。 例えば、 メ ンバ一リス ト の最新パージョンに関する情報が保存されたネッ トワーク上に配置された データベースに、 同報通信と同じまたは、 異なるプロ トコル （例えば、 同 報通信で S M T Ρを利用す場合には、 L D A P、 O C S Pなど） を利用し て、最新のメンバ一リス 卜のバージョンを問い合わせるようにしてもよい。
[第 5— 2 dの実施形態]
本発明の情報中継装置の第 5— 2 dの実施の形態は、 第 5— 1 dの実施 の形態の情報中継装置 4 f に、 リ ス ト正当性確認部 4 d f をさらに備える 構成をとる。 137 リス ト正当性確認部 4 d f は、 メ ンバ一リス トを取得した場合に、 メ ン バーリス ト正当性の検証を行う。 このメンバ一リストの正当性の検証を行 なう機能は、 前述のメ ンバーリ ス ト管理装置 1 ίの実施の形態で説明した とう りである。
[第 5 — 3 dの実施形態]
本発明の情報中継装置の第 5 - 3 dの実施の形態は、 第 5 — 1 dまたは 第 5 — 2 dの実施の形態の情報中継装置 4 ε に、 付加情報添付部 4 c s を さらに備える構成をとる。
付加情報添付部 4 c £ は、 チームマスタ一または情報中継装置 4 E の管 理者による各種情報 （サービス情報、 管理情報等） を暗号情報に添付する ものである。 この付加情報を添付する機能により、 被配信メ ンバ一に幅の 広いサービスを提供することができる。
[第 5— 4 dの実施形態]
本発明の情報中継装置の第 5 — 4 dの実施の形態は、 第 5— 1 dないし 第 5 — 3 dの実施の形態のいずれかの情報中継装置 4 ί に、 同報通信安全 性検証部 4 f f をさらに備える構成をとる。 同報通信安全性検証部 4 f ίは、 第 1 の機能としてメンバーリス トの同 一性を検証する機能をもつ。 例えば、 送信側の端末が故障していたり、 通 信回線が不通となっていた場合には、 最新のメンバ一リス 卜が送信者に行 き渡っていない可能性がある。 同報通信安全性検証部 4 f ∑は、 より同報 通信の安全性を高めるために、 転送されてきた暗号情報の暗号化時に利用 したメンバーリス トと、 サーバが転送時に利用する配信先リス トを作成す るために用いたメンバ一リストとの同一性の検証を行う。 138
例えば、 メンバーリス トのバ一ジヨ ン N oやチームマスタ一がメ ンバー リストを作成したときの時間 （例えば、 タイムスタンプなどが付加されて いた場合） などの情報を利用して、 メンバーリス トが同一のものかを検証 することができる。 また、 別の手法としては、 メンバーリス トに添付され たデジタル署名者が同一かどうかを検証することにより、 同一性検証を行 うことができる。 また、 別の手法としては、 メンバーリストに対してハツ シュ関数を利用してメッセ一ジダイジエストを比較することにより、 同一 性検証を行うことができる。 また、 同報通信安全性検証部 4 f f は、 第 2の機能として同報通信送信 者を検証する機能をもつ。 従来の同報通信は、 情報中継装置 4 f の管理者 が情報の中身を見ることができたため、 例えば、 中傷 ·誹謗情報が流れて いるか否かなどの、 内容を検査することができた。 しかし、 本発明の方式 では、サーバの管理者が情報の中身を見れない仕組みを実現しているため、 この情報中継装置 4 f を不正に利用される可能性がある。 そこで、 同報通 信安全性検証部 4 f f は、 情報受信を拒否する情報端末 （例えば、 I Pァ ドレスなどによって識別できる）、 または、 利用者の識別情報 （例えば、 メールシステムの場合には、 メールア ドレスや、 信頼できる認証局より発 行された証明書などによつて識別できる） が含まれる受信拒否情報を取得 し、情報中継装置 4 £ に転送されてきた情報の送信者または、送信端末が、 受信拒否情報に含まれているか否かを検証する機能をもつ。 なお、 受信拒 否情報には、 例えば、 過去にスパムメールを発した個人のメールア ドレス や、 セキュリティレベルが低く本人識別が正当な手順をもって行われてい ない可能性がある端末の I Pァ ドレスゃネッ トワークァ ドレスのリストが 含まれている。 139
また、 同報通信安全性検証部 4 f εは、 第 3の機能として同報通信内容 を検証する機能をもつ。 これは、 同報通信の安全性を高めるために、 送信 者や通信内容についても検証を行なうものである。 暗号情報の送信者がメ ンバーリス 卜に含まれた者かどうかの検証や、 転送されてきた情報の中に 悪意あるプログラムやデータ列が含まれているかどうかの検証を行なう。 また、 同報通信安全性検証部 4 f £は、 第 4の機能として複数パーツか らなる暗号情報のうち、 情報保管装置に保存され暗号情報復号化装置から 参照されるパーツが間違いなく情報保管装置に転送されたかを検証する機 能をもつ。 転送されてきた暗号情報を参照して複数のパ一ッで構成される 暗号情報のうち、 一部を別の情報保管装置に転送しているか判別し、 一部 が別の情報保管装置に転送されている場合、 確実に転送されたかを検証す る。
さらに、 前述の暗号情報作成装置の実施の形態で説明した公開鍵やデジ タル署名に利用される秘密鍵の有効性を検証する機能は、 同報通信安全性 検証部 4 f ε に備えられ利用される形態もある。
[第 5— 5 dの実施形態]
本発明の情報中継装置の第 5— 5 dの実施の形態は、 第 5— 1 dないし 第 5— 4 dの実施の形態のいずれかの情報中継装置 4 ί に、 同報通信内容 保存部 4 g f をさらに備える構成をとる。
同報通信内容保存部 4 g f は、 転送されてきた情報、 または、 情報の一 部、 または、 それらの情報に添付情報を添付して保存する。 例えば、 メー ルシステムにおけるメールサーバに障害が発生した場合や、 受信者の端末 が故障していた場合には、 送信された情報であっても正確に受信されない 140 可能性がある。 また、 音声チャッ トにおいて通信回線の都合上、 音声が途 切れ途切れになる場合などもある。 このように送信側が送ったデータと受 信側が受け取ったデータが一致しなかった事態が発生しても、 同報通信内 容保存部 4 g £ による保存機能により安全に保存しておき、 必要になった ときに再度確認したり再取得することができる。
[第 5— 6 dの実施形態]
本発明の情報中継装置の第 5— 6 dの実施の形態は、 第 5— 1 dまたは 第 5 — 5 dの実施の形態のいずれかの情報中継装置 4 ∑ に、 同報通信自動 開設部 4 h ∑ をさらに備える構成をとる。
同報通信自動開設部 4 h ίは、 同報通信をサーバ管理者の手動の許可を 得ることなく 自動的に開始するため、 サーバ管理者が開設受付の際に開設 要求者が満たすべき項目を提示するための開設要求項目提示機能と、 開設 要求者が転送してきた開設受付要求が、 開設要求項目を満たし、 開設を許 可するか否かをを判断する開設許可判断機能と、 開設が決定されると、 開 設要求者をチームマスタ一とし、 チームマスタ一が指定したメンバーに同 報通信が可能になるよう開設設定を行う同報通信開設設定機能をもつ。 従来の同報通信システムは、 事前に情報中継装置の管理者が、 開設に伴 う作業を行う必要があった。 例えば、 配信リス トの設定や、 I Cカードを 配布したり、情報中継装置に公開鍵を登録したりする作業が必要であった。 また、 暗号同報通信は、 延々と続く通信ではなく、 例えば、 1時間の音声 チャッ ト、 3通の契約書ファイルの転送といったように、 必要なときに最 小限の時間で利用する通信であることも多いと考えられる。 その場合、 情 報中継装置 4 f の同報通信の開始や削除に関する作業負担が非常に大きく なる。 また、 ミスの発生や悪意のある管理者の存在などの危険性があるた 141 め、このような人による手動の設定はできるだけ必要としないシステムが、 安全上望ましい。 そこで、 本実施の形態の情報中継装置 4 f は、 サーバ管 理者の手動の設定を必要とすることなく、 一定の利用条件 （例えば、 利用 時間に比例する料金の支払い等） を満たせば、 自動的に同報通信を開始で きる機能を提供する。
さらに、 同報通信自動開設部 4 h f は、 開設要求者が転送してきた開設 受付要求が、 正確な要求であるかどうかを検証する開設要求確認機能を備 えてもよい。例えば、課金項目にクレジッ トカードが記されていた場合に、 クレジッ ト力一ドの番号がきちんと登録され課金可能な状態であるかを検 証する。 この検証の際に、 情報中継装置 4 f に検証に利用するデータが無 い場合には、 ネッ トワーク上に配置され所定のデータをもつデータべ一ス やサーバ等に問い合わせる。
第 5— 6 dの実施の形態の情報中継装置 4 f に、 同報通信のメンバ一の 脱退要求を受け付ける脱退要求受付部 （図示せず） を備えてもよい。
例えば、加入する意志がないのに、勝手にメンバーリス トに登録されて、 不要な情報や中傷 ·誹謗情報ばかりが転送されるという危険性がある。 本 形態の情報中継装置 4 ί では、脱退要求受付部は、同報通信のメンバーが、 情報中継装置に対して同報通信から脱退するという脱退要求が来た場合に は、 該メンバーへの転送をとりやめ、 その故をチームマスタ一に連絡する 脱退要求受付部を備える。 また、 脱退要求が、 間違いなく脱退要求メンバ —本人が作成した転送中止要求かどうかを調べるために、 デジタル署名や シェイクハンドなどの本人確認手法を利用することができる。
以上、 本発明の情報中継装置の各実施の形態を説明した。 142 次に、 本発明の同報通信システムの実施例 5— 1 として、 第三者が運用 する情報中継装置を利用して、 証券会社が証券ニュースを会員に配信する 例を説明する。 図 6 2に示す実施例 5— 1では、 メールシステムの安全な 同報通信を実現するため、 メ一リングリス ト ' サーバと WWWサーバを用 いて本発明の情報中継装置の機能を実現している。 このメ一リングリス ト ·サーバが第三者によって運用されている。 第三者が運用するメ一リングリス ト'サーバと連動した WWWサーバで、 WWWサーバには、 同報通信の開設にメ一リングリス ト 'サーバの管理者 が設定した、 開設要求者が満たすべき項目を示したホームページが保存さ れている。 証券会社は、 サ一ビスを自動開設するために、 S S L (Secure Socket Layer) 通信を利用してこのホームページをダウン口一ドし、 ブ ラウザに表示された項目に対応するフォーム内に必要事項を入力する。 本 実施例 5— 1では、 名前、 クレジッ トカード番号と 1 0 0 0人まで同報通 信できるサービスを要求することを記載して、 送信ボタンを押し、 サーバに転送する。 rサーバ上で稼動するプログラム （例えば、 C G I ) として実装さ れた同報通信自動開設部 4 h ε の開設許可判断機能は、 S S L通信で確認 したアクセスした者の証明書と、 名前、 クレジッ トカード Ν ο、 「 1 0 0 0 j の 4つデータを利用して、 開設を許可するべきか否かを判断する。 実 施例 5— 1では、 クレジッ トカード N oをクレジッ トカ一ドサ一ビス会社 に問い合わせ、 カード保持者と証明書の所有者が一致するかどうかを検証 し、 一致した場合には、 開設を許可する旨を知らせるページを加入要求者 に再度転送する。 一致しない場合には、 開設が拒否された旨を知らせるぺ ージを加入要求者に再度転送する。 143
開設を許可した場合には、 メーリ ングリス トサーバ上で稼動するプログ ラムとして実装された同報通信自動開設部 4 h ε の同報通信開設設定機能 により、 加入要求者がチームマスタ一となって管理する同報通信のための メーリングリス トア ドレスを新規に設定する。 また、 このメーリングリス トァドレスに送信されてきた情報を配信するための配信リスト （当初は、 空のリス ト） を設定する。 これらの開設設定が終了するとメーリングリス トサーバは、 チームマスタ一に対して、 開設設定が成功終了した旨を通知 するメ一ルを転送する。 実施例 5― 1におけるメンバ一リス ト管理装置 1 £ は、 例えば J A V A のァプレッ トとして実装され、 ホームページのなかに組み込まれて、 WW Wサーバに保存されている。 チームマスターは、 メンバーリス トを作成す る際に、 S S L通信を利用してダウンロードされてくるァプレツ トを用い て、 設定したいメンバーリス トの管理を行う。 本実施例 5— 1におけるメ ンバーリス トは、 チームマスターリス ト、 レポ一タ一リス ト、 受信者リス 卜の 3つのリス トで構成されている。 チームマスタ一リス トには、 チーム マスタ一以外にチームを管理できるサブマスタ一を設定し、 レポーターリ ストには、 証券二ュ一スを書く記者を登録し、 チームマスタ一のデジタル 署名を行って、 情報中継装置 4 ί に再度転送する。 情報中継装置 4 f は、 メンバ一リストが間違いなくチームマスターによって作成されているかを デジタル署名を検証した後、 配信リス トを設定する。 本実施例 5— 1での 配信ルールは、 レポ一ターリス トのメンバーから転送されてきた同報通信 情報を受信者リス ト （メンバーリス トに含まれる） に登録されたメ 分複製し、 登録するように設定されている。 144 受信者は、 基本的に毎月の課金が行えるユーザであれば自動的に加入し てもらえるよう実装するため、 本実施例 5— 1では、 メンバ一リス ト管理 部 1の加入要求受付部 1 d ί を利用する。 チームマスタ一によって設定さ れたメンバーリス 卜に含まれるチームマスタ一リス トには、 複数のサブマ スターが設定されている。 サブマスタ一もまた、 証券会社の社員であり、 このサブマスターは、 受信者リス トの管理を担当している。 サブマスタ一 は、 WWWのページとして実装された加入要求受付部 1 d f の加入要求項 目設定機能を、 S S L通信を利用してダウンロードする。 この際、 WWW サーバは、 S S L通信で取得できるサブマスタ一の証明書を見て、 サブマ スタ一本人の識別 .認証を行う。 WWWページ内のフォームの各項目を埋 めていくことによって、 加入要求項目を設定する。 本実施例では、 サ一ビ スの契約同意書、 課金項目、 メールア ドレスとメールア ドレスを含む証明 書を提示してもらう旨を指定し、 さらに、 加入要求者の加入要求を暗号化 するためのサブマスタ一の公開鍵を指定して転送する。 上記証券ニュース配信サービスへの加入要求者は、 WWWページに埋め 込まれた J A V Aァプレツ トとして実装された加入要求受付部 1 e f の加 入要求項目提示機能を利用して、 まず、 契約同意書に自分の秘密鍵を利用 してデジタル署名を行い、 また、 課金項目、 メールア ドレスを入力する。 これを転送する際には、 これらの機密情報 （特に、 課金に関する情報： ク レジッ トカード N oや銀行の口座番号等） は、 WWWサーバやメーリング リストサーバの管理者に見えてはいけないので、 サブマスタ一の公開鍵を 取得して暗号化を行ってから、 WWWサーバに転送する。 また、 以上の通 信は、 S S Lで行われているため、 認証を行う際に証明書も確認すること ができる。 145 多数の加入要求者からの加入要求は、 WWWサーバに喑号化された加入 要求情報として保存されている。 実装例 5— 1では、 加入要求受付部 l e Eの加入許可判断機能を実装したプログラムは、 WWWサーバにアクセス し、 暗号化された加入要求情報を取得し、 各項目がサービス加入を許可で きるよう満たされているかどうかを判断する。 例えば、 鍵有効性検証機能 を利用して、公開鍵と秘密鍵がまだ有効であるかを検証する。判断の結果、 加入を許可または、 拒否した旨を示す通知メールを加入要求者に対して転 送する。 このプログラムは、 さらにメンバ一リス ト管理装置を自動操作す ることができる。 許可が出された加入要求に対しては、 メ ンバ一リス ト管理装置 1 f を利 用して、 WWWサーバに保存されたメンバ一リス トを、 メンバ一リス ト取 得保存部 1 c ίを利用して取得し、 メンバ一リス トのうち、 受信者リス ト に加入要求者をを登録する。 このメ ンバ一リ ス トには、 サブマスタ一とし て登録されているサブマスタ一の秘密鍵を用いてこの受信者リストに対し てデジタル署名を添付し新メンバ一リス トとして、 再度 WWWサーバに転 送する。 WWWサーバでは、 前述のメ ンバーリス トの正当性を検証する機 能を利用してメンバーリ ス トの正当性を確認し、 さらに公開鍵やデジタル 署名に利用される秘密鍵の有効性を検証する機能を利用してメンバーリス トに含まれている公開鍵がすべて有効であるかを検証する。 これらの検証 結果が肯定であれば、 配信先リ ス ト管理部 4 a ί を利用して配信先リスト を更新する。 また、 レポ一タ一リス トに含まれているメンバ一に対しては、 最新のメ ンバ一リス トをリ ス ト送信部 1 d £ (実施例では、 S M T Pプロ トコルを利用して実装されている） を利用して、 送信しておく。 記者が証券ニュースを作成する端末は、 汎用的なコンピュータ （本実施 146 例 5— 1では、 ノートブックパソコン等） などに、 電子メールソフトゥェ ァが組み込まれている。 この電子メールソフ トウエアを利用して作成した 記事をメーリングリス トのァドレスを指定して転送しようとする。この時、 この電子メ一ルソフ トウエアと連動するプラグィン ' ソフトウェアとして 実装された暗号情報作成装置 2 ίは、 宛先検査部 2 c ε を利用して、 メ一 リングリス トア ドレスがメンバ一リス 卜の存在する情報中継装置 4 £ に転 送しょうとしていることを確認する。 この場合、 プラグイン ' ソフ トウェアは、 まず、 リ ス ト取得保存部 2 a を利用して、 端末のパソコンに存在するメンバーリス 卜のバージョンが最 新のバ一ジョンかを検証する。 これは、 ネッ トワーク上に X . 5 0 0の標 準に基づいて構築されたリ ソースデータベースに対して最新のバ一ジョン を、 L D A Pを利用して問い合わせる。 最新のバージョンでなかった場合 には、 リソースデータベースに登録された最新バージョンの所在場所から 最新のメンバ一リス トを取得する （実施例では、 WWWサーバより、 S S L通信を利用して取得する）。 暗号情報作成装置 2 f では、 メンバ一リス 卜の正当性を検証する機能を 利用してメンバ一リス トの正当性を確認後、 メンバ一リス トに含まれる受 信者リス トのメンバーの公開鍵を利用して暗号化部で、 暗号化を行う。 こ の際に、 デジタル署名付加機能は、 記者が保有する秘密鍵を記録した I C カードから、 この記者の秘密鍵を取得し、 作成された記事に対してデジタ ル署名を添付する。 このデジタル署名により、 受信者は、 どの記者が書い た記事かを確認でき、 記事の信頼性を確かめることができる。 また、 記事 を配信した記者は、 記事を作成したこと否認できなくなる。 147 メーリングリス 卜のァドレスに送信されたメ一リングリス トは、 まず、 同報通信安全性検証部 4 f E を利用して送信された情報のデジタル署名添 付者 （本実施例 5 — 1では、 記者） 力；、 間違いなくメ ンバ一リス トのうち のレポ一ターリス トに含まれているか確認する。 また、 メンバ一リス トの 同一性を検証する機能を利用して、 メンバ一リス トのバージョンが異なつ ていないかを検証する。 検証した結果、 メンバ一リス トのバージョンが異 なる場合には、 その旨を明示した情報と同報通信情報をこの記者に対して 返信する。 以上の検証の結果、 すべて正常であれば、 情報複製部 4 b ε を 利用して暗号情報を複製し、 メンパーリス トの受信者リストに含まれるメ ンバ一に対して、 S M T Ρプロ トコルで実装された送信部 4 c f を利用し て送信する。 受信者の電子メールソフ トウエアに組み込まれたプラグィン ' ソフ トゥ エアとして実装された本発明の暗号情報復号化装置は、 複号化部 3 b εの デジタル署名を検証する機能を利用して改竄の有無および情報作成者を確 認して、 送信者が証券会社の記者であることを確認する。 確認後記事を復 号化して、 記事を読むことができる。 記事を無事複号化できた時点で、 受 信通知発信部 3 c £ を利用して、 情報中継装置 4 £ に対して受信通知を送 信する。 なお、 本実施例における J A V Αァプレツ 卜が本当に悪意がないかどう かをチェックするには、 J A V Aァプレツ 卜に添付されたデジタル署名を 確認することによって、 検証できる
以上、 実施例 5― 1における各装置の動作を説明した。 次に、 本発明の同報通信システムの実施例 5— 2として、 複数の企業間 148 にまたがるメンバ一間 （この集合を、 チーム 0 0 1 £ とする） で見積もり や商談等の機密情報を同報通信して行う場合に利用される例を説明する。 図 6 3に示す実施例 5— 2では、 情報中継装置としてメーリングリス トサ ーバを利用する。 チーム 0 0 1 f のチームマスタ一は、 汎用的なデスク トップコンビュ一 タの O S上に実行ファイルとして実装されたメンバ一リスト管理装置 1 ε を利用して、 機密情報を同報通信するメンバーリス ト管理を行う。 リス ト 取得保存部 1 c f を利用してメンバーリス トを取得し、 リ ス ト作成 ·変更 G U I 画面を開く。 この G U I 画面には、 チーム 0 0 1 £ のメンバ一の一 覧と、 公開鍵管理部 1 b £ を利用して端末にある公開鍵のデータベースに アクセスし、 保存されている公開鍵の一覧を表示している。 チーム 0 0 1 f のチームマスターは、 公開鍵一覧から、 チームに加入す るメンバ一の公開鍵を選択し、チーム 0 0 1 εのメンバ一一覧に追加する。 また、 公開鍵管理部 1 b Ϊが提供するネッ トワークアクセス機能を利用し て、 ネッ 卜ワーク上の認証局が提供するディ レク トリ一サ一ビスにァクセ スし、 端末になかった公開鍵で新たにチーム 0 0 1 ί に追加したいメンバ —の公開鍵を取得し、 この公開鍵をメンバ一リス トに加える。
G U I画面には、 Ο Κボタンが表示されており、 チーム 0 0 1 ίのメン バ一を変更し終わったら、 この Ο Κボタンを押す。 この時点で、 公開鍵や デジタル署名に利用される秘密鍵の有効性を検証する機能は、 メンバ一リ ス トに含まれるそれぞれの公開鍵が含まれる証明書を発行した認証局のデ ィ レク トリサービスに L D A Pプロ トコルを利用してアクセスし、 この公 開鍵が有効であるかどうかを検証する。 検証の結果、 無効の公開鍵があれ 149 ば、 その旨をダイアログに表示して、 チームマスターに通知する。 すべて 有効であれば、 タイムスタンプと、 メ一リングリス トのア ドレスとチーム I Dとチームマスターの識別名で構成されるメンバーリス トを作成し、 こ のメンバ一リストの全体のデータをハッシュ関数の M D 5を利用して圧縮 し、 圧縮データを生成する。 次に、 チームマスターの秘密鍵にアクセスし、 チームマスタ一がダイァ ログボックスより入力したパスヮードを利用したパスヮード複号化 （実施 例では、 共通鍵暗号方式 R C 2を利用して実装されたパスヮード復号化を 利用する） を行う。 その結果取得した、 チームマスタ一の秘密鍵を利用し て、 圧縮データを公開鍵暗号方式 R S Aで、 暗号化することにより、 デジ タル署名を作成する。 このメンバーリス トとデジタル署名を情報中継装置 4 f に S M T Pプロ トコルを利用してメールとして転送する。 情報中継装置 4 ε では、 配信先リス ト管理部 4 a f のメンパーリス ト取 得機能を利用して、 受信したマルチパー ト （M I M E (Multipurpose Internet Mail Extensions) ) のフォーマツ 卜で構成された S M T Pメー ルの中身を解析し、 C o n t e n t— T y p eより判断したメンバ一リス ト部分を抽出して、 リス ト正当性確認部 4 d ί に入力する。 リス ト正当性 確認部 4 d Εは、 メンバーリス 卜のデジタル署名者として間違いなくチー ム 0 0 1 f のチームマスターのデジタル署名が添付されていることを確認 し、 配信先リス ト管理部 4 a を利用して、 配信先リス トの受信者を変更 する。 その後、 変更されたばかりの配信先リス トの受信者に対して、 メン バ一リストとデジタル署名を M I M Eフォーマッ トごと複製し、 配信先リ ス 卜の各受信者に対して転送する。 150 汎用的なデスク トップコンピュータ上にインス トールされたメ一ラ一と して動作する暗号情報作成装置 2 ε は、 メンバ一リス トが含まれたメール を受け取った場合には、 M I M Eの C o n t e n t — T y p eより、 この メールが同報通信におけるメンバ一リス トであることを識別する。 その時 点で、 メ一ラ一は、 メンバーリス トとデジタル署名を抽出し、 リス トの正 当性を検証する機能を利用して、 メンバ一リス トの正当性を確認した後、 リス ト取得保存部 2 a ε を利用して保存しておく。 チーム 0 0 1に含まれるメンバーが、 汎用的なデスク トップコンビュ一 タ上で可動する一般的な実行プログラムとして実装された暗号情報作成装 置 2 f の同報通信情報作成機能を利用して、 見積書と契約書の 2つの添付 ファイルを含むメールを作成した後、 送信ボタンを押すと、 宛先検査部 2 c £が送信先ァドレスをチェックし、 送信先ァドレスが端末に保存されて いる複数メンバ一リス トのうち、 送信先ァドレスのために私用するメンバ —リス トがあるかを検査する。 メンバーリス トがあった場合には、 この添付ファイルとメールを、 メン バ一リス トの公開鍵を利用して暗号化する。 その際に、暗号化部 2 b εは、 それぞれの添付ファイルとメ一ル本文を別々に暗号化し、 デジタル署名も 個々に添付する。 これらの複数のパーツで構成された情報の内、 添付ファ ィルはそのまま添付せずに、 情報保管装置 （情報保管サーバ） 5 εに転送 する。複数パーツ送信部 2 d ί は、情報中継装置 4 £のァドレスをもとに、 メ一リングリス トア ドレスに対応する情報保管装置 5 ε をネッ トヮ一ク上 のデータベースに問い合わせ、 2つの添付ファイルを送信すべき情報保管 装置 4 ί のア ドレスと、 送信方法 （例えば、 プロ トコルなど） を特定する。 151 情報保管装置 5 £ は、 H T T Pプロ トコル利用したファイル転送を許可 する仕組みであることが分かると、 H T T Pプロ トコルを利用して送信す る。 その際に、 情報保管装置 5 £は、 S S L通信を利用しユーザ認証が可 能であるため、 ユーザがメ一リングリス トサーバで行っている同報通信サ —ビスを利用しているメンバーリス 卜に含まれているかを確認することが できる。 メール本文は 2つの添付ファイルの送信とは別に、 情報保管サ一 バのァ ドレスを添付してァ ドレスを転送する。 メーリ ングリス トのァ ドレスに送信されたメーリ ングリス トは、 まず、 同報通信安全性検証部 4 f f を利用して送られてきた情報のデジタル署名 添付者が、 間違いなくメンバーリス トのうちのレポーターリ ス トに含まれ ているか確認する。 また、 メンバーリス トの同一性を検証する機能を利用 して、 メンバ一リス トのバ一ジョンが異なっていないかを検証する。 検証 の結果、 メンバ一リス トのバージョンが異なる場合には、 その旨を明示し た情報と同報通信情報を記者に対して返信する。 また、 同報通信安全性検 証部 4 f f の同報通信内容検証機能を利用し、 通信内容の中に、 装置ゃソ フトウエアのバグを利用した悪意あるプログラムやウィルスなどが含まれ ていないかを検証する。 さらに、 同報通信安全性検証部 4 f £ の情報保管 装置参照機能を利用して、 間違いなく暗号化された 2つ添付ファイルが情 報保管装置 4 Eに転送されて保存されているかを検証する。 以上の検証の結果、 すべて正常であれば、 同報通信内容保存部 4 g £ を 利用し、 同報通信の内容をメ一リングリス トサーバに接続されたデータべ ースに保存しておく。 その際に、 タイムスタンプとメーリングリス トサー バの秘密鍵を利用したデジタル署名を添付して保存する。 また、 暗号情報 には、 情報保管装置 4 ί に添付ファイルが保存されていることを確認した 152 事に関する時間と、 この喑号情報が、 メーリングリス トサーバに保存され ている事に関する情報を添付して、 情報複製部 4 b f を利用して暗号情報 と添付情報を複製し、 メンバ一リス トの受信者リス トに含まれるメンバ一 に対して、 S M T Ρプロ トコルで実装された送信部 4 c £を利用して送信 する。 出張先の WWWブラウザで、 メールを取得しようとしているユーザは、 J A V Aアブレツ トとして実装された暗号情報復号化装置 3 £ を、 ダウン ロードしブラゥザ上でこの喑号情報を受信する。 この J A V Aァプレツ ト は、 ネッ トワーク上より リスト取得保存部 3 f £ を利用してメンバーリス トの最新バージョンを取得し、リス 卜の正当性を検証する機能を利用して、 メンバ一リス トがチ一ムマスター本人によって、 作成されたものかどう力 を確認する。 この暗号情報を取得した際に、 まず、 復号化部 3 b ε のデジ タル署名を検証する機能を利用して改竄 ·情報作成者を確認し、 さらに、 同報通信安全性検証部 3 e E の送信者信頼性確認機能を利用して、 メンバ 一リス トに含まれる商談相手であることを確認する。 その後、 複号化部 3 b ί を利用し、 情報を複号化して暗号情報を見ると情報保管装置 5 ί に添 付ファイルが送信されていることが判明する。複数パーツ受信部 3 d f は、 この添付ファイルを H T T Pプロ トコルを利用してダウンロードし、 それ それのファイルを再度復号化し、 もとの情報を得ることができる。
以上、 実施例 5— 2における各装置の動作を説明した。 なお、 本発明は、 インタ一ネッ トの他、 L A Nやダイアルアップによる ネッ トヮ一クを利用してもよい。
また、 本発明のメンバ一リス ト管理装置を実現するためのプログラムを コンピュータ読み取り可能な記録媒体に記録して、 この記録媒体に記録さ 153 れたプログラムをコンピュータシステムに読み込ませ、 実行することによ りメンバ一リス ト管理を行ってもよレ、。 すなわち、 このメンバ一リス ト管 理プログラムは、 同報通信を行う 1以上のメンバ一の公開鍵を含むメンバ —リス トを作成する機能と、 前記公開鍵を取得し保存する機能とをコンビ ュ一タに実現させる。 また、 本発明の暗号情報作成装置を実現するためのプログラムをコンビ ュ一タ読み取り可能な記録媒体に記録して、 この記録媒体に記録されたプ 口グラムをコンピュータシステムに読み込ませ、 実行することにより喑号 情報作成を行ってもよい。 すなわち、 この暗号情報作成プログラムは、 ネ ッ トヮ一クを介して、 メンバーリス トを取得し保存する機能と、 同報通信 文を取得し、 該同報通信文を前記メンパーリストに含まれる公開鍵を用い て暗号化し暗号化情報とする機能とをコンピュータに実現させる。 また、 本発明の暗号情報復号化装置を実現するためのプログラムをコン ピュータ読み取り可能な記録媒体に記録して、 この記録媒体に記録された プログラムをコンピュータシステムに読み込ませ、 実行することにより喑 号情報複号化を行ってもよい。 すなわち、 この暗号情報復号化プログラム は、 情報中継装置から転送された暗号情報を取得する機能と、 前記暗号情 報に含まれる暗号化情報を復号化する機能とをコンピュータに実現させる。 また、 本発明の情報中継装置を実現するためのプログラムをコンビュ一 タ読み取り可能な記録媒体に記録して、 この記録媒体に記録されたプログ ラムをコンピュータシステムに読み込ませ、 実行することにより情報中継 処理を行ってもよい。 すなわち、 この情報中継処理プログラムは、 配信先 リス トを管理する機能と、 転送されてきた暗号情報を複製する機能と、 複 154 製された暗号情報を各被配信メ ：一に配信する機能とをコンビ. タ 実現させる。 また、 モバイルネッ トワーク環境においても同報通信を実現するため、 同報通信に必要な本発明のメンバーリス ト管理装置、 暗号情報作成装置、 暗号情報復号化装置を持たない端末を利用しなければならない場合でも、 この端末にネッ トワーク上に配置され各装置のそれぞれの機能を実現する ソフトウエアを保存しているソフ トウユア保管装置から、 各装置の機能を 実現するソフ トウエアをダウンロードして、 端末に内蔵されたコンビュ一 タシステムに読み込ませ実行させることにより、 同報通信を行なってもよ レ、。 以上詳細に説明したように、 第 5— l a〜 5— 4 a， 第 5— l b〜 5— 3 b , 第 5 — l c〜 5— 5 c , 第 5— 1 c！〜 5 — 6 dの実施形態の発明に よれば、 以下の効果がある。
本発明によれば、 情報中継装置において暗号化された情報を複号化しな い仕組みとしたので、 情報中継装置の管理者による同報通信の通信内容の 漏洩や改竄等の不正を防ぎ、 本当に情報を共有する必要のあるメンバ一に だけ同報通信内容を共有することができる。
また、 本発明によれば、 メンバ一リス ト管理部に加入要求受付部を、 そ して情報中継装置に同報通信自動開設部を設けたので、 同報通信を行う受 信者の脱退や、 加入に対して迅速に対応でき、 同報通信メンバーの動的な 変更があっても、 誤って同報通信してはいけないメンバ一に情報を転送し てしまうことを防止できる。
また、 本発明によれば、 メンバ一リス 卜による管理を行なうので、 情報 中継装置の管理者が同報通信の被配信メンバ一を管理するのではなく、 同 155 報通信を行うメンバーの中で被配信メンバ一を管理でき、 さらにメンバー の管理者に集中する管理負担を軽減することができる。
また、 本発明によれば、 情報中継装置において同報通信安全性検証部お よび同報通信内容保存部を設け、 暗号情報複号化装置において受信通知発 信部および同報通信安全性検証部を設けたので、 多数の被配信メンバ一そ れぞれが、 情報を確実に受信できる。
[第 6の実施形態]
第 6の実施形態の発明は、 企業の部や課といった組織単位に相当するチ —ムの構成員 （ユーザないしメ ンバ） 間で各種の情報やユーザに提供され る様々な機能を共有するためのチームデータリス トを作成， 管理， 保管し、 それによつて、 これら情報や機能をユーザ間でチーム毎に安全に共有して ゆくためのチームデータリスト処理システムに関するものである。 さらに 詳細には、 チームデータリ ス トの保管に係わる処理を担うチームデータリ ス ト保管装置と、 チームデータリス ト保管装置から取得したチームデータ リス トを対象として様々な管理を行うチームデータリス ト管理装置を備え たシステムに関するものである。 第 6の実施形態の発明に関し、 従来以下説明する技術が知られている。 ユーザに提供される各種の情報や機能といった様々な資源を複数のュ一 ザ間で共有するためには、これら資源にアクセスを要求しているユーザが、 本当に資源へアクセスする権利を有しているのか否かを検証する機能を用 意しておく必要がある。 かかる検証を行うために、 従来は、 資源に対する 正当なアクセス権限を付与されたユーザを予め定義したアクセスコント口 —ルリス ト （以下、 「A C L」 と略記する） と呼ばれるリス トを利用して いる。 なお、 ここで言う A C Lは、 上述したチームデータリス トに含まれ 156 る種々の情報のうち、 共有資源に対するアクセスを制御するための情報だ けが含まれたリストの一例である。 図 7 6は、 A C Lを利用して複数のユーザ間で情報共有を行う従来のシ ステムの概要を示したものである。 同図に示されるシステムでは、 イント ラネッ ト 1 ζ， ィンタ一ネッ ト 2 ζがそれぞれファイアウォール 3 ζ， 4 ζを介してサーバ 5 ζに接続されており、 イントラネッ ト 1内部の者ばか りでなく、 イントラネッ ト外の共有メンバ 6 ζがインタ一ネッ ト 2 ζを介 して互いに情報を共有している。 周知のように、 イントラネッ ト 1 ζは企 業内に整備されたネッ トワークなどの閉じたネッ トワークであり、 その一 方で、 インターネッ ト 2は世界中にまたがるパブリックなネッ トワークで ある。 また、 ファイアウォール 3 ζ， 4 ζは悪意を持った侵入者などがイント ラネッ ト 1 ζへ不正にアクセスすることを防止するためのコンピュータで ある。 サーバ 5 ζは各種の資源が蓄積されている端末 （コンピュータ） で あって、 共有情報が格納されたデータベース 7 ζ と、 特定の情報ないし機 能にアクセスしても良いグループ及びそれに属するメンバのメンバリス ト を保持した A C L 8 ζを備えている。 このサーバ 5 ζは、 データべ一ス 7 ζに蓄積されている共有情報を管理するデータ保管機能のほか、 クライア ントに相当する通信相手が予め許可されている者か否かを検証するユーザ 認証機能， A C L 8 ζに基づいて共有情報に対するアクセスの可否を検証 するアクセス制御機能， A C L 8 ζに基づいて特定のグループに属するメ ンバだけが特定の共有情報へアクセスすることを可能ならしめるグループ 管理機能を備えている。 157 · 図 7 6のシステムでは、 共有メンバ 6 ζゃィントラネッ ト 1 ζ内部のュ —ザからデータベース 7 ζに対するアクセス要求があると、 サーバ 5 ζは その都度 A C L 8 ζを参照してユーザ認証を行い、 当該ュ一ザがメンバと して A C L 8 ζに定義されていればアクセスを許可し、 メンバとして定義 されていなければアクセスを拒否する。 また、 当該ユーザに対してァクセ スが許可されている場合、 サーバ 5は A C L 8 ζを参照して当該メンバが 特定のグループに含まれるかどうかを確認するとともに、 当該メンバがァ クセス要求のある共有情報に関してアクセスを許されているかどうか調べ るようにしている。 一方、 図 7 7は特定グループに属するメンバだけで情報を共有するため の従来の一実現例を示したものであって、 図中のサーバ S V ζは図 7 6の サーバ 5 ζに対応し、 クライアント は図 7 6の共有メンバ 6 ζゃィ ントラネッ ト 1 ζ内部の者が操作する端末である。 図 7 7では、 サーバ S V ζ上にメンバーリス ト 9 ζを設けている。 グル一プ毎に存在するメンバ —リス ト 9 ζは、 当該グループに付与されている識別子であるグループ I D , グループ内の各メンバの公開鍵， これら公開鍵に付与されている識別 子である公開鍵番号 （図中の公開鍵 N o ) で構成されており、 当該グルー プのチームマスタ一のデジタル署名が付されている。 クライアント C L がグループ I Dを指定してある特定のグループに関 するメンバ一リス トをサーバ S V ζに要求すると、 サーバ S V ζは所定の 権限確認を行ったのちに、 指定されたグループ I Dに対応するメンバーリ スト 9 ζを公開鍵 I Dリス トとしてクライアント C L に転送する。 クラ イアント C L ζは当該リス 卜に含まれるチームマスタ一のデジタル署名が 正当なものであることを確認したのち、 送られたメンバーリス トをグルー 158 プに対するメンバの加入， 退会などに応じて当該メンバの公開鍵及び公開 鍵 I Dを追加， 削除することによってメンバ一リ ス ト 9 a ζを作成する。 次いで、 クライアント C L ζはメンバーリス ト 9 a ζにデジタル署名を行 レ、、 サーバ S V ζにメンパーリスト更新要求を行ってメンバ一リス ト 9 a ζを返送する。 これにより、サーバ S V ζは所定の権限確認を行ったのち、 クライアント C L からのメンバーリス ト 9 b ζを受け取ってサーバ S V ζ上のグループの更新処理を行う。 ところで、 複数のユーザ間で資源を共有する場合にはサーバ側の管理者 を共有メ ンバに含めるのが好ましくない場合もある。 例えば、 ある企業の 情報システム部に所属するシステム管理者は、 人事部内だけで共有すべき 企業の人事情報にアクセス不可能であることが必要と考えられる。 ところ 、 上述した図 7 6のようなシステムや図 7 7の処理手順では、 サーバ 5 ζやサーバ S V ζ の管理者に対して A C L 8 ζ の設定や管理を行う権限を 許与してしまっている。 そのため、 これらサーバ管理者は A C L 8 ζに対 して不正なアクセスを行うことが可能であり、 意図的に A C L 8 ζの設定 内容が改竄されるのを防止することができない欠点がある。これに加えて、 サーバ管理者以外にも、 サーバ S V ζへ不正に侵入する者 （いわゆるクラ ッカ） によって A C L 8 が不正に改竄されてしまうおそれもある。 また、 上述したような従来のシステムでは、 限られた少数のサーバ管理 者に権限の設定を行ってもらう必要があるため、 こう した権限設定作業に 関わる負担がこれら少数の管理者に集中してしまうという問題もある。 し かも、 イントラネッ ト内部でだけ情報を共有するような形態であればまだ しも、 例えば企業のシステムを企業外の第三者に委託して運営させるよう な利用形態では、 情報の共有者の増減などによって A C L 8 Cの設定を変 159 更する必要が生じると、 その都度、 企業外の運営者に対して設定作業を依 頼する必要がある。 したがって、 それに要する手間や費用が大きな負担に なるほか、 外部の運営者を本当に信頼できるかといった信頼性の点におい ても問題が残ってしまう。 第 6の実施形態の発明は上記の点に鑑みてなされたものであり、 その目 的は、 チームデータリス トが保存されているサーバの管理者にチームデー タリス 卜の管理を行わせずに、 チームデータリス トの管理者であるグルー プ内のメ ンバ自身がチームデータリストを管理でき、 サーバ管理者， メン バではあるが管理者ではない者， クラッカなどがチームデータリス トを不 正に変更することを未然に防止できるチームデータリス ト処理システムを 提供することにある。 また、 本発明の別の目的は、 チームデータリス トの 管理者として複数の者を設定できるようにして特定の個人にかかる作業負 担を軽减することのできるチームデータリス ト処理システムを提供するこ とにある。 さらに、 本発明の他の目的は、 サーバ管理者等の外部の者を介 在することなくチームデータリス トの管理者であるメンバ自身がチームデ —タリス 卜の管理者の変更を行うことができるチームデータリスト処理シ ステムを提供することにある。 以下、 図面を参照して第 6の実施形態について説明するが、 まず初めに 本発明におけるチームデータリ ス トについて説明する。 本発明におけるチ —ムデータリス トは、 チームに関する情報を定義したリ ス 卜の総称であつ て、 上述した A C Lのような機密性の高い管理が要求される用途に適用さ れる 「メンバの集合」 を定義するためのものである。 上述した通り、 従来 のシステムでは、 チームのメンバではない端末管理者， ネッ トワーク管理 者， サーバ管理者などがチームに関する情報を変更することができる。 一 160 方、 本発明におけるチームデータリス トでは、 チームに関する情報を複数 のリス ト （後述するような 1つ以上のメ ンバリス トとチームマスタ リス ト） に分割して管理することで、 チームマスタ自身の変更といったチーム 管理をチーム内のメンバだけで行えるようにしている。 次に、 図 6 7ないし図 6 8を参照して本発明の前提となる技術について 説明しておく。 図 6 7は、 本発明が前提とするシステムの構成をおおまか に描いたものであって、 ネッ トワーク NW ζを介してクライアント とサーバ S V ζを接続して構成されたシステムである。 図中、 メンバリス トは各種の情報やユーザに提供される機能等の資源にアクセスできるメン バを記述したものである。 また、 サーバ S V ζはハードディスク上などに 構築されたデータベース 1 0 ζに接続しており、 このデータベース 1 0 ζ には複数のメンバが属するグループ （図中のグループ Α ζ， Β ζ ) にそれ ぞれ対応したメンバリス ト 1 1 Α ζ， 1 1 Β ζが記憶されている。 サーバ S V ζはメンバリス ト保管機能だけを備えており、 クライアント C L ζにメンバリス トを転送するほか、 クライアント C L が変更を行つ て返送してく るメンバリス 卜でデータベース 1 0 ζ上のメンバリス ト 1 1 Α ζやメンバリス ト 1 1 Β ζの内容を置き換える。 その一方で、 クライア ント C L ζはメンバリス 卜管理機能を具備している。 このメンバリス ト管 理機能の一つにメンバリス 卜の変更機能があり、 クライアント C L ζはサ —バ S V ζから取得したメンバリス トにメンバの追加や削除に応じた修正 を行ってサーバ S V ζに返送するようにする。 ここで、 いま説明した機能だけでは、 サーバ管理者ゃクラッカなどがサ —バ S V ζを操作することによって、 クライアント C L 側のメンバリス 161 ト管理機能を介在することなくサーバ S V ζ 上のメンバリス トを改竄でき てしまう。 しかも、 サーバ管理者などが自らのデジタル署名で不正にメン パリ ス トを改竄するとク ライアン ト C L からは正当な管理者と区別でき ないという問題が生じる。 この種の不都合を回避するために、 図 6 7のシ ステムではメンバリ ス ト 1 1 Α ζ， 1 1 Β ζにそれぞれデジタル署名 1 2 Α ζ， 1 2 Β ζを付加している。 また、 これに対応するようにクライアン ト C L ζはメンバリスト管理機能の一環としてデジタル署名機能を備えて おり、 秘密鍵ファイルや秘密鍵の記録された I C (集積回路） カード等か ら秘密鍵を取得し、 メ ンバリス 卜に対してこの秘密鍵を用いたデジタル署 名を施してサーバ S V ζに送出するとともに、 サーバ S V ζがメンバリス トとデジタル署名をグループ毎に対で保管するようにしている。 こうする ことで、 メンバリス 卜に付属するデジタル署名を確認することによって、 サーバ管理者などがメンバリス 卜の一部を不正に書き替えたことをクライ アント C L ζ側で見つけることができる。 一方、 図 6 8はクライアント C L ζ側からサーバ S V ζ上のメンバリス トを変更する場合の手順の概要を示したものである。 サーバ S V ζ上に保 管されているメンバリス ト 2 0 ζには、 情報共有グループたるチーム Τ 1 ζを構成しているメンバ. M X ζ， M Y ζ , ■· · , M B ζ (実際は、 次に述べ るような各メ ンバに対応した公開鍵番号） に加えて、 当該チームの管理者 たるチームマスタ Τ Μ ζ (詳細は後述） のデジタル署名が予め登録されて いる。 まず、 メンバリ ス トを変更する場合、 クライアント C L ζ側にいるチー ムマスタ Τ Μ ζは、 グループないしチームを識別するためのグループ I D (識別子） と、 公開鍵方式におけるユーザ公開鍵 （即ち、 所定長のビッ ト 162 列） に対応したユーザ公開鍵番号 （図中のュ一ザ公開鍵 N o ) をサーバ S ν ζに送って、 メンバリス トを送るようにサーバ S V ζへ要求する （ステ ップ S l ）。 なお、 ここで言う 「ユーザ公開鍵番号」 は、 チームマスタ T M ζなどのユーザ本人を識別 .認証するための情報であって、 各ュ一ザ 公開鍵に予め付与されているシリアル番号のことである。 さらに詳しく説 明すると、 ユーザ公開鍵番号はユーザ公開鍵を一意に識別するための各ュ —ザ公開鍵に対応した情報であって、 例えば、 認証局から発行された証明 書に含まれている当該証明書のシリアル番号である。 また、 ユーザ本人を 識別 ·認証するための情報としては、 いま述べたユーザ公開鍵番号以外に も、 実際に鍵作成者本人を識別する I Dや名前などの様々な情報を利用す ることができる。 ちなみに、 これ以後の説明ではこう したユーザ本人を識 別 ·認証するための情報の一例として公開鍵番号を用いた場合について説 明を行う。 次に、 サーバ S V ζはクライアント C L から送られてくるグループ I D , ユーザ公開鍵番号に基づいて以下に詳述するようにチームマスタ Τ Μ ζの権限を確認する （ステップ S 2 )。 まず、 サーバ s v は 「シヱイ クハンド」 又は 「チャレンジレスポンス」 と呼ばれる手法を用いてチ一ム マスタ Τ Μ ζ本人の識別 ·認証を行う。 以下、 この処理について図 6 9に 示した手順に沿って説明する。 まず、 図 6 8のステップ S 2 ζのところで 説明したように、 クライアント C L ζからサーバ S V ζへのアクセスの際 にユーザ名やユーザ公開鍵 （実際には上述したユーザ公開鍵番号） をサ一 バ S V ζ側に送付しておく （ステップ S 1 0 1 ζ )。 次に、 サーバ S V ζ は乱数を発生させて内部に記憶するとともにこの乱数を （ユーザ公開鍵番 号に対応する） ユーザ公開鍵で暗号化 （ステップ S 1 0 2 ζ ) し、 暗号化 されたデータを 「チャレンジデータ」 としてクライアント C L ζに送信す 163 - る （ステップ S 1 0 3 )。 クライアン ト C L ζはサーバ S V ζから送ら れたチヤレンジデータをユーザ公開鍵に対応した秘密鍵で復号化 （ステツ プ S 1 04 ) し、 得られた復号化データを 「チャレンジレスポンス」 と してサーバ S V ζに返送する （ステップ S 1 0 5 ；)。 サーバ S V はク ライアント C L Cから送られたチャレンジレスポンスとステップ S 1 02 ζで発生させた乱数とを比較して通信相手を確認する。 すなわち、 両者が 一致すればステップ S 1 0 1 ζで送付されたユーザ公開鍵に対応する秘密 鍵を知っている者が通信相手であることを確認 （認証成功） することがで きる。 これに対し、 両者が不一致であれば通信相手が正当な権限を持った 者でない可能性のある （認証失敗） ことがわかる （以上、 ステップ S 1 0 6 ζ )。 この後、 サ一バ S V ζはステップ S 1 0 6 ζで得られた確認結果 (認証成功または認証失敗） をクライアント C L ζに通知する （ステップ S 1 0 7 ζ )。 このようにして仮に本人の認証が成功したならば、 サーバ は、 ク ライアント C L ζから送られたユーザ公開鍵番号がメンバリス ト 20 ζに 記載されているかどうかを確認するとともに、 ユーザ （この場合はチーム マスタ ΤΜζ ) がメンバリス ト 20 ζを変更する権限を持っているかどう か確認する。 ここでは、 クライアント C L ζから送られたュ一ザ公開鍵番 号が、 グループ I Dで指定されたチーム Τ 1 ζに対応するメンバリス ト 2 0 ζ中に記載されているものとする。 ちなみに、 ユーザ公開鍵番号がメン バリス ト 20 ζ上に記載されていなければ、 サーバ S V ζは認証失敗をク ライアント C L ζに通知する。 次に、 サーバ S V は、 メンバリス ト 20 中のデジタル署名がチームマスタ ΤΜ ζのものであることから、 サーバ S V ζはチームマスタ ΤΜ ζによるメンバリス トの書き換え要求を了承し、 要求されたメンバリス ト 20 Cをクライアント C L 側へ転送する （ステ 164 ップ≤ 3 ζ )。 クライアン ト C L は、 メンバリス ト 2 0 ζ内のデジタル 署名を調べ、 当該デジタル署名がチームマスタ Τ Μ ζ 自身の付与したもの であることから、 メ ンバリ ス ト 2 0 ζがサーバ S V ζ側で改竄されておら ず正当なものであることを確認する （ステップ S 4 ）。 次に、 クライア ント はメンバリス ト 2 0 ζ中のメンバ M B ζをメンバ M C ζに置き 換えるメンバ変更処理を行ってメンバリスト 2 1 ζを作成する （ステップ S 5 ζ )。 ここで、 作成されたメンバリ ス ト 2 1 ζではメンバ変更の折り にデジタル署名を削除してあるので、 クライアント C L ζはメンバリスト 2 1 ζにチームマスタ Τ Μ ζのデジタル署名を付加したメンバリス ト 2 2 ζを作成 （ステップ≤ 6 ζ ) し、 これをサーバ S V ζに返送する （ステツ プ S 7 ζ )。 以上のようなことから、 本発明ではメンバリス 卜の管理自体はクライア ン ト C L ζ側において各チーム内のメンバの中から選ばれた管理者が行う ものとし、 サーバ S V ζ側では先に説明したサーバ管理者に相当する者や クラッカ等の無権限の者がメンバリストを不正に改竄できない構成を採用 することにしている。 そして、 以下に詳述する本実施形態は、 いま述べた 前提技術を土台としてこれをさらに発展させたものであって、 以下に述べ る機能を盛り込むことで上述した本発明の目的を達成している。 第一に、 多数の人間を抱える部署のメンバリス 卜を管理をするにあたって、 一人の 管理者にかかる負担を軽減するために、 複数の管理者でメンバリス トを管 理する機構を実現する。 第二に、 チームデ一タリス トの管理者自身による チームデ一タリス トの管理者の変更を実現する。 例えば、 チームデータリ ス トの管理者である部長が異動になって後任の部長を新たなチームデータ リス トの管理者とする場合などである。 そう した場合、 チームデータリ ス 卜の管理者たる現在の部長自身が管理者権限を後任の部長に権限委譲でき 165 るようにするほか、 この権限委譲に際してサーバ管理者等の第三者が介入 する余地のないようにしている。 そこで以下、 チームデータリス ト管理装置及びチームデータリス ト保管 装置の 2つの装置を備えたシステムについて本実施形態を説明してゆく。 図 6 6は、 チームデータリス ト管理装置及びチームデータリス ト保管装置 を具備した本実施形態のシステム全体の構成を示したプロック図である。 同図において、 チームデータリス ト管理装置 3 0 ζ， チームデータリス ト 保管装置 3 1 ζは以下に詳述するチームデータリス ト管理機能， チームデ —タ リス ト保管機能をそれぞれ備えており、 互いに通信機能を利用してデ —タを授受している。 チームデ一タリス ト管理装置 3 0 ζ， チームデータ リスト保管装置 3 1 ζは何れもワークステーションなどの一般的なコンビ ュ一タで実現することが可能であり、 これらコンピュータの主記憶上には それぞれチームデータリス ト管理機能， チームデータリスト保管機能を実 現するためのプログラム （チームデータリス ト管理プログラム， チームデ —タリス ト保管プログラム） が記憶される。 これらのプログラムはフロッピ一ディスク， I C (集積回路） カード， 光磁気ディスク， C D— R O M (コンパク トディスク一読み取り専用メモ リ） 等の可搬性のある記憶媒体や、 コンピュータに内蔵されるハードディ スクなどの大容量の記憶媒体といったコンピュータ読み取り可能な記憶媒 体にその一部又は全部が記憶されている。 すなわち、 当該プログラムは以 下に詳述する機能の一部を実現するためのものであっても良く、 さらには コンピュータにすでに記録されているプログラムとの組み合わせでこれら 機能を実現できるものであっても良い- そして
、 チームデータリス 卜管理装置やチームデータリス 卜保管装置を作動させ 166 るにあたって、 これらのプログラムがコンピュータ上の C P U (中央処理 装置） の指示の下に予め記憶媒体から主記憶上に転送される。 その後、 C P Uは主記憶上に転送されたプログラムを実行し、 それによつて装置各部 を制御して、 以下に詳述する様々な処理を実現している。 本実施形態では、 チームデータリストにアクセスできる者をその権限の 内容に応じてメンバ， サブマスタ， チームマスタの 3種類に分類しており、 この順番でその者に付与される権限が拡大してゆく。 サブマスタはチーム マスタによって指名されたチーム内の管理者であって、 チームマスタゃサ ブマスタを変更することはできないが、 一般のメンバに関して追加， 削除 といった変更を行うことのできる者である。 一方、 チームマスタはサブマ スタ又はメンバの変更を行えるほか、 自身のチームマスタでさえ変更する ことのできる者である。 他方、 サブマスタ及びチームマスタ以外の一般の メンバは情報や機能を共有する者であって、 チームデータリス 卜の内容に 変更を加える等の権限はいつさい与えられていない。 なお
、 サブマスタやチームマスタは特別な権限が与えられてはいるが、 チーム 内のメンバであることに変わりはなく、 その意味でサブマスタ又はチーム マスタをメンバと呼ぶことがある。 さて、 図 6 6に示すチームデータリスト保管装置 3 1 ζにはハ一ドディ スク等といったデータベースを構築可能な記憶装置 3 2 ζが接続されてい る。 この記憶装置 3 2 ζは、 複数のメンバで構成されるチーム毎にメンバ リス ト 3 3 ζ とチームマスタリス ト 3 4 ζからなるチームデータリス トの 組を記憶している。 同図では説明の都合からメンバリス ト 3 3 ζ及びチ一 ムマスタリス ト 3 4 ζの組を一つだけ示しているが、 実際にはチームの数 だけこれらの組が存在している。 メンバリス ト 3 3 Cはユーザに提供され 167 る情報や機能を共有するメ ンバの一覧で構成されており、 メンバの識別情 報， メンバに与えられた公開鍵， この公開鍵に対応する秘密鍵の保有者の I D (以下 「公開鍵 I D」 という）， チームを識別するチーム I D， リ ス ト作成者 （即ち、 チームマスタ又はサブマスタ） のデジタル署名， 当該メ ンバリス ト 3 3 ζが作成された時間を示すタイムスタンプ， チーム内のメ ンバが利用できる機能 （例えば、 アプリケーショ ン） に関する情報， 会社 組織になぞらえてチームを階層化するための情報などが含まれている。 こ のほ力 、 メンバリス ト 3 3 ζには各メンバに関する情報として、 e— m a i 1 (電子メール） ア ドレスやメ ンバ自身の住所といった情報も含まれて おり、 これらを用いることで各メンバに関する情報リ ソースの管理も同時 に行うことができる。 一方、 チームマスタリス ト 3 4 ζはチームマスタ及 びサブマスタの一覧で構成されており、 チームマスタ又はサブマスタの識 別情報， 公開鍵， 公開鍵 I D， チーム I D， チームマスタのデジタル署名， 当該チームマスタ リス ト 3 4 ζが作成された時間を示すタイムスタンプな どが含まれる。 このほか、 チームマスタリス ト 3 4 ζには、 チームに関す る情報としてチームのメ ンバ数， チームの作成された時間， チ一ム内の各 メンバが利用することのできる各種機能などの情報も含まれており、 これ らを用いることで各チームに関する情報リ ソースの管理を同時に行うこと ができる。 次に、 図 6 6のチームデータリス ト保管装置 3 1 ζにおいて、 権限確認 機能 3 5 ζはクライアン ト C L ζ側からメンバリ ス ト 3 3 ζやチームマス タリス ト 3 4 ζに対する変更要求ないし参照要求があつたときに、 これら 2つのリス 卜の内容に基づき、 クライアント C L 側の要求者自身の認証 を行うほか、 この要求者が変更ないし参照を行う正当な権限を有する者か どうか確認して、 クライアント C L C側へメンバリス ト 3 3 ζやチームマ 168 スタ リス ト 3 4 ζを転送すべきかどうかを判断する。 また、 リ ス ト保管機 能 3 6 ζは権限確認機能 3 5 ζがメンバリス ト 3 3 ζやチームマスタリス ト 3 4 ζを使用するにあたって、 これらのリス トを記憶装置 3 2 ζから取 得しあるいは記憶装置 3 2 ζへ保存する処理を司っている。 以下の説明で は、 権限確認機能 3 5 ζがメンバリス ト 3 3 ζやチームマスタ リス ト 3 4 ζを使用する場合には必ずリス ト保管機能 3 6 ζが介在することを前提と しているが、 煩雑になるため一々説明しないことにする。 次に、 チームデータリ ス ト管理装置 3 0 ζにおいて、 リス ト作成者確認 機能 3 7 ζはチームデータリス ト保管装置 3 1 ζからメンバリス ト 3 3 ζ 又はチームマスタリス ト 3 4 ζを取得し、 それらリス 卜が管理権限を持つ 管理者 （即ち、 チームマスタ又はサブマスタ） によって作成されているか どうかを検証する。 この検証によって、 サーバ S V ζ の管理者やサーバ S V ζへ不正に侵入したクラッカ等の無権限の者がメンバリス ト 3 3 ζゃチ —ムマスタリス ト 3 4 ζを改竄したことを検知することができる。 リス ト 変更機能 3 8 ζは、 リス ト作成者確認機能 3 7 ζが取得したメンバリス ト 3 3 ζやチームマスタリス ト 3 4 ζに対してメンバゃ管理者の追加，削除， 置換などの変更を加えるものである。 また、 デジタル署名機能 3 9 ζはリ スト変更機能 3 8 ζによって変更されたメンバリス ト 3 3 ζやチームマス タリス ト 3 4 ζに対し、 変更者本人しか知り得ない秘密鍵ないしデジタル 署名鍵を用いた暗号とハッシュ関数とを併用してこれらリス トの変更者 (即ち、 チームマスタ又はサブマスタ） のデジタル署名を付加する。 一方、 公開鍵管理機能 4 0 ζは、 チームデータリス ト管理装置 3 0 ζに接続され た公開鍵データベース 4 1 ζにアクセスして、 公開鍵と当該公開鍵に対応 する公開鍵 I Dを取得する。 ちなみに、 実際の形態においては、 公開鍵デ —タベース 4 1 はチームデータリ スト管理装置 3 0 ζに直接的に接続さ 169 れた口一カルな形態のみならず、 インターネッ ト等のネッ トヮ一ク上に設 置されたサーバ （例えば、 認証局） に存在している形態も当然に考えられ る。 こうした形態によれば、 公開鍵管理機能 4 0 ζは例えば認証局上に登 録されたホームページを介して公開鍵データベース 4 1 ζにアクセスし、 そこから上述した公開鍵及び公開鍵 I Dをフアイルの形式で取得すること も可能になる。 なお、 図 6 6では公開鍵データベース 4 1 ζ， 記憶装置 3 2 ζをそれぞ れチームデータリス ト管理装置 3 0 ζ， チームデータリスト保管装置 3 1 ζ とは別構成としているが、 例えば、 チームデータリ ス ト管理装置 3 0 ζ に公開鍵データベース 4 1 ζを含めても良く、 また、 チームデータリ ス ト 保管装置 3 1 ζに記憶装置 3 2 ζを含めても良いのはもちろんである。 次に、 上記構成によるチームデータリスト管理装置 3 0 ζおよびチーム データリスト保管装置 3 1 ζを有するシステムの動作について説明する。 まず、 図 7 0は複数の管理者によってメンバを管理してゆく際の動作のう ち、 メンバリ ス トに登録されているメンバの変更を行うための処理手順を 示したものである。 チームデータリス ト保管装置 3 1 ζにおいて、 チーム マスタリス ト 4 5 ζに対応するチーム Τ 2 ζは前述したチームマスタ Τ Μ ζが作成したものであるため、 チームマスタであるメンバ M X ζのデジタ ル署名が付与されている。 このチームマスタ リス ト 4 5 ζでは、 チームマ スタとしてメンバ M X ζ， サブマスタとしてメンバ M Y ζ及びメンバ Μ Ζ ζが登録されている。 なお以下の説明では、 あるメンバがチームマスタ又 はサブマスタである場合、 それらメンバ （例えば図 7 0に示したメンバ Μ ， メンバ！^丫 ） をそれぞれチームマスタ M X ζ， サブマスタ M Y ζ などと表記することがある。 170 .
〔メンバの変更〕
以下では、 人事異動等でメンバ MB ζがメンバからはずれてメンバ MC ζが新たなメンバとして加入する場合を想定する。 そのため、 サブマスタ MY ζがチーム Τ 2 ζに属するメンバ MB ζをメンバ MC ζに置き換える ものとする。 まず、 チームデータリス ト管理装置 30 ζはチーム Τ 2 ζを 表すグループ I Dおよびサブマスタ MY ζのユーザ公開鍵番号とともに、 メンバの変更要求をチームデータリス ト保管装置 3 1 ζに送出する （ステ ップ S 1 1 ζ )c チームデータリ ス 卜保管装置 3 ζにおいて、 権限確認 機能 3 5 ζは上述したシェイクハンドによってサブマスタ MY ζの認証を 行ったのち、 グループ I Dで指定されるチーム Τ 2 ζに関わるメンバリス ト 46 ζを参照してメンバ MY ζのユーザ公開鍵番号が当該メンバリス ト 46 ζ上に存在することを確認するとともに、 チームマスタリスト 4 5 ζ を参照することによって、 サブマスタ MY ζがチーム T 2 ζのサブマスタ であってメンバの変更権限を有していることを確認する （ステップ S 1 2 ζ )0 次いで、 権限確認機能 3 5 ζは指定されたチーム Τ 2 ζに関するチ —ムマスタ リ ス 卜 4 5 ζ及びメ ンバリ ス 卜 4 6 ζをチームデータ リ ス ト管 理装置 30 ζ側に転送する （ステップ S 1 3 )。 チームデータリス ト管理装置 30 ζにおいて、 リス ト作成者確認機能 3 7 ζはチームデータリスト保管装置 3 1 ζから転送されてきたチームマス タリス ト 4 5 ζ及びメンバリス ト 46 ζに含まれているデジタル署名を照 合して、これらリス 卜がチームマスタリス ト 4 5 ζに登録されている者（即 ち、 チームマスタ ΜΧ ζ ) によって作成された正当なものであることを確 認する （ステップ S 1 4 ζ )c 171 ここで、 図 7 1のフ口一チヤ一卜に基づいてリス 卜作成者確認機能 3 7 ζが実施する確認処理の詳細について説明しておく。 まず、 リスト作成者 確認機能 3 7 ζはチームマスタ リス ト 4 5 ζ及びメンバリス ト 4 6 ζをチ —ムデ一タリスト保管装置 3 1 ζから取得 （ステップ S 2 1 ζ ) し、 次い で、 これら 2つのリス トに含まれるデジタル署名を確認する （ステップ S 2 2 ζ ) 0 この確認の結果、 何れか一つでもデジタル署名が改竄されてい るのであれば、 不正行為が発生していると考えられるためいま行っている メンバ変更などの処理を中止する。 一方、 改竄が検出されなかったのであ れば、 リス ト作成者確認機能 3 7 ζはメンバリス ト 4 6 ζのデジタル署名 者 （即ち、 図 7 0ではメンバ M X ζ ) がチームマスタ リス ト 4 5 ζにチー ムマスタ又はサブマスタとして含まれていることを確認し、 含まれていな いのであれば不正行為があったものとしてステップ S 2 2 ζにおけるのと 同様に現在行っている処理を中止する （ステップ S 2 3 ζ )。 これに対して、 メンバリス ト 4 6 ζのデジタル署名者がチ一ムマスタリ スト 4 5 ζに含まれているのであれば、 メンバリス ト 4 6 ζの正当性につ いては確認されたことになり、 リ ス ト作成者確認機能 3 7 ζは引き続いて チームマスタリス ト 4 5 ζのデジタル署名者 （即ち、 図 7 0では同じくメ ンバ Μ Χ ζ ) がチームマスタであるかどうかを確認 （ステップ S 2 4 ζ ) し、 チームマスタでなければステップ S 2 2 ζ〜ステップ 3 2 3 ζ と同様 に、 不正行為が発生したものとして処理を中止する。 一方、 チームマスタ リスト 4 5 ζのデジタル署名者がチームマスタであるならば、 チームマス タリス ト 4 5 ζについても正当性が確認されたことになり、 これ以後の処 理を続行する。 例えば上記の場合で言えば、 リス ト作成者確認機能 3 7 ζ がリス ト変更機能 3 8 ζに対してチームマスタリスト 4 5 ζ及びメンバリ ス ト 4 6 ζを送出する。 172
こうしてチームマスタリスト 4 5 ζ及びマスタリス ト 4 6 ζの正当性が 確認されたならば、 図 7 0のステップ S 1 5 ζにおいて、 リス ト変更機能 3 8 ζはメンバリス ト 4 6 ζに記述されているメンバ M B ζをメンバ M C ζに置き換えてメンバリ ス ト 4 7 ζを作成し、 これをデジタル署名機能 3 9 ζに送出する。 デジタル署名機能 3 9 ζは前述した秘密鍵ファイル等か らサブマスタ M Y ζに関する秘密鍵を取得し、 これを基にメンバリス ト 4 7 ζへサブマスタ M Y ζのデジタル署名を添付したメンバリス ト 4 8 ζを 作成 （ステップ S 1 6 ζ ) したのち、 チ一ムマスタリス ト 4 5 ζ及びメン バリス ト 4 8 ζをチームデータリス ト保管装置 3 1 ζに返送する （ステツ プ S 1 7 ζ )。 チームデータリス ト保管装置 3 1 ζにおいて、 権限確認機能 3 5 ζは転 送されてきたチームマスタリス ト 4 5 ζ及びメンバリス ト 4 8 ζについて デジタル署名が改竄されていないかどうか検証するとともに、 以下のよう にしてこれらリ ス トの内容を検証する。 すなわち、 チームマスタリス ト 4 5 ζのデジタル署名者はチームマスタ M X ζであることからその正当性が 分かる。 一方で、 メンバリス ト 4 8 ζのデジタル署名者はサブマスタ M Y ζであって、 正当性の確認されたチームマスタリスト 4 5 ζを参照するこ とでこのサブマスタ M Y ζがチームマスタ M X ζからメンバ変更を許可さ れた者であることが分かるため、 メンバリス ト 4 8 ζについてもそれが正 当なものであることを信頼できる。 これに対して、 転送されてきたリス ト について正当性が確認できない場合、 権限確認機能 3 5 ζはチームマスタ リス ト及びメ ンバリス トを更新することなく処理を中止する （以上、 ステ ップ S 1 8 ）。 以上のようにしてメ ンバリ ス ト中のメンバ変更が行われ たことになる。 173
〔サブマスタの変更〕
次に、 チームマスタがサブマスタを変更する際の処理手順について図 7 2を参照して説明する。 以下では、 チーム T 2に属するチームマスタ M X ζカ 、 サブメンバたるメンバ M Y ζをメンバ MW ζに置き換える場合を想 定する。 チームマスタ M X ζがチ一ムデータリスト管理装置 3 0 ζに対し てサブマスタをメンバ M Y ζ力ゝらメンバ MW ζへ変更する要求を行うと、 チームデータリス ト管理装置 3 0 ζにおいてリス ト作成者確認機能 3 7 ζ は図 7 0のステップ S 1 1 ζ と同じくグループ I D及びチームマスタ M X ζのユーザ公開鍵番号とともにサブマスタの変更要求をチ一ムデータリス ト保管装置 3 1 ζに送出する （ステップ S 3 1 ζ )。 チームデータリス ト 保管装置 3 1 ζにおいて、 権限確認機能 3 5 ζは図 7 0のステップ S 1 2 ζで説明したのと同様の手順に従って、 シヱイクハンドによりチームマス タ M X ζの認証を行ったのち、 メンバ M X ζのユーザ公開鍵番号がメンバ リス ト 4 6 ζに記載されていることを確認するとともに、 メンバ M X ζが チーム Τ 2 ζのチームマスタであってサブマスタの変更権限を与えられて いることを確認する （ステップ≤ 3 2 ζ )。 次に、 権限確認機能 3 5 ζは 図 7 0のステップ S 1 3 ζ と同様にしてチームマスタリスト 4 5 ζ及びメ ンバリス ト 4 6 ζをチームデータリス ト管理装置 3 0 ζに転送する （ステ ップ S 3 3 ζ )。 チームデータリスト管理装置 3 0 ζにおいて、 リス ト作成者確認機能 3 7 ζは転送されてきたチームマスタリス ト 4 5 ζに含まれているデジタル 署名を調べる。 これにより、 リス ト作成者確認機能 3 7 ζはこのチームマ スタリスト 4 5 ζがチ一ムマスタたるメンバ M X ζによって作成された正 当なものであることを確認し、 チームマスタリス ト 4 5 ζ及びメンバリス 174 ト 4 6 ζ をリス ト変更機能 3 8 ζ に渡す （ステップ S 3 4 ζ )。 リス ト変 更機能 3 8 ζはチームマスタリス ト 4 5 ζに記述されているサブマスタ Μ Υ ζをサブマスタ MW Cに置き換えたチームマスタリス ト 5 1 ζを作成し、 これをデジタル署名機能 3 9 ζに送出する （ステップ S 3 5 ζ )。 デジタル署名機能 3 9 ζは、 前述した秘密鍵ファイル等からチームマス タ M X ζに関する秘密鍵を取得し、 メンバリ ス ト 5 1 ζに対してチームマ スタ M X ζ のデジタル署名を添付したチームマスタ リ ス ト 5 2 ζを作成 (ステップ S 3 6 ) したのち、 チームマスタリスト 5 2 ζ及びメンバリ スト 4 6 ζをチームデータリス ト保管装置 3 1 ζに返送する （ステップ S 3 7 ζ )。 チームデータリス ト保管装置 3 1 ζにおいて、 権限確認機能 3 5 ζは転送されてきたチームマスタ リス ト 5 2 ζ及びメンバリス ト 4 6 ζ の内容を図 7 0のステップ S 1 8 ζ と同様の手順に従って検証する。 この 場合、 チームマスタリス ト 5 2 ζ及びメンバリス ト 4 6 ζのデジタル署名 者は何れもチームマスタ M X ζであることからその正当性が分かる。 これ に対して、 転送されてきたリス トについて正当性が確認できない場合、 権 限確認機能 3 5 ζはチームマスタリス ト及びメンバリス トを更新すること なく処理を中止する （ステップ≤ 3 8 ζ )。 以上のようにして、 チームマ スタ リ ス ト中のサブマスタの変更が行われたことになる。 なお、 図 7 2に示した事例では元々のメンバリス ト 4 6 ζのデジタル署 名がチームマスタ M X ζのものであつたが、 仮にこれがサブマスタ M Y ζ のデジタル署名であっても問題はない。 すなわち、 サブマスタの変更権限 を有するチームマスタ M X ζは必ずメンバリス ト 4 6 ζについて自身のデ ジタル署名を付与することができる。 そこでこの場合は、 チームデ一タリ スト管理装置 3 0側でメンバリ ス ト 4 6 ζからサブマスタ M Y ζ のデジタ 175 ル署名を削除し、 その代わりにチームマスタ M X ζのデジタル署名を添付 してチームデータリス ト保管装置 3 1 ζに返送するようにする。 こうする ことで、 メンバではなくなったサブマスタ M Y ζのデジタル署名がなされ たメンバリス 卜がチームデータリス ト保管装置 3 1 ζ側に残ることはなく なる。
〔チームマスタ自身の変更〕
次に、 チームマスタがチームマスタ自身を変更する際の処理手順につい て図 7 3に沿って説明する。 以下では、 チームマスタ M X ζがチームマス タ Μ Κ ζに権限委譲してチームマスタの交代を行う場合を想定している。 チームデータリス ト保管装置 3 1 ζに保管されているチームマスタ リス ト 4 5 ζは図 7 0又は図 7 2に示したものと同じであって、 メンバリス ト 4 8 ζは図 7 0に示したメンバ変更後のものと同じである。 まず、 チームマスタ M X ζがチームデータリス ト管理装置 3 0 ζに対し てチームマスタをメンバ Μ Κ ζに変更する要求を行うと、 リ ス ト作成者確 認機能 3 7 ζは、 図 7 0のステップ S 1 1 ζ と同様にして、 グループ I D 及びチームマスタ M X ζ のユーザ公開鍵番号とともにチームマスタ リス ト 4 5 ζ及びメンバリス ト 4 8 ζの参照要求をチームデータリス ト保管装置 3 1 ζに送出する （ステップ S 4 1 ζ )。 チ一ムデータリス ト保管装置 3 1 ζにおいて、 権限確認機能 3 5 ζは図 7 0のステップ S 1 2 ζで説明し たのと同様の手順に従って、 シェイクハンドによりメンバ M X ζの認証を 行ったのち、 メンバ M X ζのュ一ザ公開鍵番号がメンバリス ト 4 8 ζに存 在することを確認するとともに、 メンバ M X ζがチーム Τ 2 ζのチームマ スタであって要求しているリス 卜の参照権限が与えられていることを確認 する （ステップ S 4 2 ζ )。 176
次に、 権限確認機能 3 5 ζは図 7 0のステップ S 1 3 ζ と同様にして指 定されたチーム Τ 2 ζに関するチームマスタ リス ト 4 5 ζ及びメンバリス ト 4 8 ζをチームデータリス ト管理装置 3 0 ζに転送する （ステップ S 4 3 ζ )。 このとき、 権限確認機能 3 5 ζは後刻に行われる権限確認で使用 するためにチームマスタ リス ト 4 5 ζを保存しておく。 次に、 チームデ一 タリスト管理装置 3 0 ζにおいて、 リス ト作成者確認機能 3 7 ζは転送さ れてきたチームマスタリス ト 4 5 ζ， メンバリス ト 4 8 ζのデジタル署名 をそれぞれ調べ、 各々がチームマスタ リ ス ト 4 5 ζに含まれるチームマス タ MX ζ , サブマスタ MY ζによって作成された正当なものであることを 確認する （ステップ≤ 4 4 ζ )。 これによ り、 リ ス ト作成者確認機能は転 送された 2つのリ ス トをリ ス ト変更機能 3 8 ζに渡す。 次に、 リス ト変更機能 3 8 ζはチームマスタ リス ト 4 5 ζ， メンバリス ト 4 8 ζに記述されているチームマスタたるメンバ MX ζをメンバ ΜΚ ζ に置き換え、 それぞれチームマスタ リ ス ト 5 5 ζ， メンバリ ス ト 5 6 ζ を 作成してこれらをデジタル署名機能 3 9 ζに送出する （ステップ S 4 5 ζ )。 デジタル署名機能 3 9 ζは前述した秘密鍵ファイル等からチームマ スタ MX ζに関する秘密鍵を取得し、 チームマスタリス ト 5 5 ζ及びメン バリス ト 5 6 ζにそれぞれチームマスタ MX ζのデジタル署名を添付した チームマスタ リス 卜 5 7 ζ及びメンバリス ト 5 8 ζを作成してチームデ一 タリス ト保管装置 3 1 ζ に返送する （ステップ≤ 4 6 ζ )。 チームデータリス ト保管装置 3 1 ζにおいて、 権限確認機能 3 5 ζは転 送されてきた 2つのリス 卜と先のステップ S 4 3 ζで保存しておいたチー ムマスタリス ト 4 5 ζ (即ち、 旧チームマスタ リス ト） の 3つのリス トに 177 基づき、 図 7 4に示すフローチャートに従って権限確認を行う （ステップ S 4 7 ζ )。 また、 図 7 5はかかる権限確認を行う際に、 図 7 4の各ステ ップで比較照合されるチームマスタリス トゃメ ンバリス 卜の様子を示した ものである。 まず、 権限確認機能 3 5 ζは新旧のチームマスタリス トとしてそれぞれ チームマスタ リ ス ト 5 7 ζ， 4 5 ζを取得するとともに、 新メンバリスト としてメンバリス ト 5 8 ζを取得する （ステップ S 6 1 ζ )。 次に、 権限 確認機能 3 5 ζはチームマスタリス ト 5 7 ζ及びメンバリス 卜 5 8 ζのデ ジタル署名をそれぞれ調べる （ステップ≤ 6 2 ζ )。 もし何れかでも改竄 されているのであれば、 これら 2つのリス 卜がチームデータリス ト管理装 置 3 0 ζ (クライアント C L ） からチームデータリス ト保管装置 3 1 ζ (サーバ S V C ) へ転送される過程で不正行為が発生しているため、 権限 確認機能 3 5 ζはチームマスタ変更処理を中止する。 一方、 転送された 2つのリス トが何れも改竄されていなければ、 権限確 認機能 3 5 ζは新チームマスタリス ト 5 7 ζのデジタル署名を調べて、 そ れが旧チームマスタ リス ト 4 5 ζ のデジタル署名者と同じチームマスタ Μ Χ ζによるものであることを確認する （ステップ S 6 3 ζ ) c これは、 元々 チームマスタであった者から権限委譲が為されていることを確認するため であって、 もしステップ S 6 3 ζの判断結果が " N O " となれば、 権限違 反などによる不正行為があると考えられるのでチームマスタ変更処理を中 止する。 もっとも、 この場合はチームマスタリス ト 5 7 ζにメンバ M X ζのデジ タル署名が添付されているので、 権限確認機能 3 5 ζは引き続いて、 チー 178 ムマスタ自身の変更とこれ以外の通常の変更とを判別するために、 新チー ムマスタリス ト 5 7 ζのデジタル署名者がマスタ権限を有しているかどう か確認する （ステップ S 6 4 )。 例えば、 前述した図 7 0で説明したメ ンバ変更においてはチームマスタリス ト 4 5 ζのデジタル署名がマスタ権 限を持つメンバ MX ζによるものであり、 このことは図 7 2のサブマスタ 変更におけるチームマスタ 5 2 ζについても同じである （即ち、 ステップ ≤ 6 4 ζ の判断結果が "Y E S " となる場合）。 一方、 チームマスタ自身を変更する場合であるが、 図 7 3のステップ S 4 7 ζの処理時点はメンバ MX ζからメンバ ΜΚ ζに権限委譲する移行期 に相当しており、 チームマスタ リ ス ト 5 7 ζは新管理者たるメンバ ΜΚ ζ がマスタであって且つ旧管理者たるメンバ MX ζがデジタル署名した過渡 的な状態になっており、 チームマスタリス ト 5 7 ζのデジタル署名者がマ スタ権限を持っていないように見える。 こう した状態が検出されてチーム マスタ自身の変更を認識 （ステップ S 6 4 ζの判断結果が "NO") した ならば、 権限確認機能 3 5 ζは新メンバリス ト 5 8 ζ のデジタル署名を調 ベ、 そのデジタル署名が新チームマスタ リ ス 卜 5 7 ζに含まれている力 、 さもなければ、 新旧何れかのチームマスタ リ ス ト 5 7 ζ， 4 5 ζのデジタ ル署名者であるかどうかを確認する （ステップ≤ 6 5 ζ )。 もし、 何れの 条件も満足しないのであれば改竄等の不正行為が発生していると考えられ るため、 権限確認機能 3 5 ζはチームマスタ変更処理を中止する。 もっと も、 この場合はメンバリ ス ト 5 8 ζのデジタル署名者が新旧チームマスタ リス ト 5 7 ζ， 4 5 ζ のデジタル署名者と同じであるため、 権限確認機能 3 5 ζは正規の手続きを経てメンバリス トが作成されたものと判断するこ とができる。 以上述べたステップ S 6 2 ζ〜ステップ≤ 6 5 ζの処理によ つて、 正当な権限を持つチームマスタ MX による正常な操作でチームマ 179 スタ自身が変更されたものと判断することができる。 この後、 権限確認機能 3 5 ζは新旧チームマスタ リス ト 5 7 ζ， 45 ζ とメ ンバリ ス ト 5 8 ζをチームデータリ ス ト管理装置 3 0 ζ に送出する (ステップ S 48 )。 これ以後の処理は新たなチームマスタ MK ζの指 示の下に行われるものであって、 チ一ムマスタリス ト 5 7 ζ とメンバリス ト 5 8 ζのデジタル署名をチームマスタ ΜΚ ζのデジタル署名で書き替え るための処理である。 チームデータリス ト管理装置 3 0 ζにおいて、 リス ト作成者確認機能 5 7 ζは転送されてきた各リ ス トに含まれるデジタル署 名を確認する （ステップ≤ 4 9 ζ )。 すなわち、 リス ト作成者確認機能 3 7 ζは旧チームマスタリス ト 4 5 ζ と新メンバリスト 5 8 ζのデジタル署 名が何れも改竄されていないことを確認し、 次いで新旧チームマスタリス ト 5 7 ζ， 4 5 ζのデジタル署名が互いに一致しているかどうかを確認し、 さらには旧チームマスタリス ト 4 5 ζの内容をもとに当該リス 卜のデジタ ル署名者たるメンバ MX ζがチームマスタの権限を持っているかどうかを 確認する。 この場合は、 いま述べた 3つの条件を全て満足しているため、 リス ト作成者確認機能 3 7 ζはチームマスタ リ ス ト 5 7 ζ とメ ンバリ ス ト 58 ζをリス ト変更機能 3 8 ζに渡す。 次に、 リス ト変更機能 3 8 ζがチームマスタ リス ト 5 7 ζ及びメンバリ ス ト 58 ζを基にチームマスタリス ト 5 9 ζ及びメンバリス ト 60 ζを作 成してデジタル署名機能 3 9 ζに渡す。 デジタル署名機能 3 9 ζは前述し た秘密鍵ファイル等からメンバ ΜΚ ζに関する秘密鍵を取得し、 チームマ スタリスト 5 9 ζ及びメンバリス ト 60 ζの各々にメンバ ΜΚ ζのデジタ ル署名を添付してチームマスタリス ト 6 1 ζ及びメンバリス ト 6 2 ζを作 成し、これらのリス トをチームデータリス ト保管装置 3 1 ζに返送する（ス 180 テツプ S 5 0 ζ )。 チームデータリス ト保管装置 3 1 ζにおいて、 権限確 認機能 3 5 ζは転送されてきたチームマスタ リ ス ト 6 1 ζ及びメンバリス ト 6 2 ζに対して図 7 4に示した処理手順に従って権限確認を行う （ステ ップ S 5 1 ）。 この場合は、 これら 2つのリ ス トのデジタル署名者が何 れもチ一ムマスタ M K ζであるため、 これら 2つのリス 卜が何れも正当な ものであると判断することができる。 なお、 この場合は通常の変更である ため図 7 4のステップ S 6 4 ζによる判断結果は " Y E S " となる。 し力 るに、 もし転送されてきたリス 卜について正当性が確認できないのであれ ば、 権限確認機能 3 5 ζはチームマスタリス ト及びメンバリス 卜を更新す ることなく処理を中止する。 以上によってチームマスタ自身の変更がなさ れたことになる。 なお、 図 7 3に示したステップ S 4 7 ζ力 らステップ S 5 1 までの移 行期の間において、 チームデータリスト管理装置 3 0 ζからチームデータ リス ト保管装置 3 1 ζに対してメンバリス ト参照要求， メ ンバリス ト変更 要求， マスタ変更要求がなされた場合、 チームデータリ ス ト管理装置 3 0 ζ及びチームデータリス ト保管装置 3 1 ζでは以下のようにリ ス 卜作成者 の確認が行われる。 まず、 チームデータリス ト管理装置 3 0 ζからメンバリス ト参照要求が あると、 チームデ一タリス ト保管装置 3 1 ζは旧チームマスタリス ト 4 5 ζ と新メンバリス ト 5 8 ζをチームデータリス ト管理装置 3 0 ζに転送す る。 チームデ一タリス ト管理装置 3 0 ζにおいて、 リ ス ト作成者確認機能 3 7 ζは転送されてきた 2つのリストのデジタル署名が改竄されていない かどうかを確認したのち、 旧チームマスタリス ト 4 5 ζの内容をもとに当 該リ ス トのデジタル署名者 （図 7 3の場合はメ ンバ M X ζ ) がチームマス 181 タの権限を持っているかどうかを確認する。 一方、 チームデータリス ト管理装置 3 0 ζからメンバリス ト変更要求又 はマスタ変更要求があると、 チームデータリス ト保管装置 3 1 ζは新旧チ —ムマスタ リス ト 5 7 ζ， 4 5 ζ及び新メンバリ ス 卜 5 8 ζをチームデー タ リス ト管理装置 3 0 ζへ転送する。 チームデータリス ト管理装置 3 0 ζ において、 リス ト作成者確認機能 3 7 ζはメンバリス ト参照要求の場合と 同様に、 転送されてきた 2つのリス 卜のデジタル署名が改竄されていない かどうかを確認する。 次に、 リ ス ト作成者確認機能 3 7 ζは新旧チームマ スタリス ト 5 7 ζ， 4 5 ζのデジタル署名を互いに比較してこれらが一致 しているかどうかを確認する。 次いで、 リス ト作成者確認機能 3 7 ζはメ ンバリス ト参照要求の場合と同様に、 旧チームマスタ リス ト 4 5 ζのデジ タル署名者がチームマスタの権限を持っているかどうかを確認する。
〔チームマスタ確認の自動化〕
上述した実施形態では、 チームデータリ ス トを使用する都度、 チームマ スタが間違いなく本物であるかどうかをュ一ザがクライアント C L ζ側で 確認する必要がある。 例えば、 チームデータリ ス ト管理装置 3 0 ζを構成 するコンピュータのディスプレイ上に、 "このリス トは以下のメンバが管 理者となって正常に管理されています。 名前： メンバ M X ζ， 組織： 三菱 マテリアル株式会社。 作業を続行する場合は Ο Κボタンをマウスでクリッ クして下さい" などといったメッセージが表示される。 このように、 ユー ザが当該メッセージを目視で確認する必要が生じてくるため、 ユーザに対 して煩わしい印象を与える可能性がないとは言えない。 こう した点を改善 するには以下の機能をリス ト作成者確認機能 3 7 ζ と連携する新たな機能 として追加し、 あるいは、 リス ト作成者確認機能 3 7 ζ の一機能として組 182 み込むようにすることで解決される。 すなわち、 チームマスタの公開鍵をチーム毎に予めクライアント C L ζ 側の例えば公開鍵データベース 4 1 ζ (図 6 6参照） に登録しておき、 公 開鍵管理機能 4 0 ζが公開鍵データベース 4 1 ζからチームマスタの公開 鍵を取得してこれをリス ト作成者確認機能 3 7 ζに通知する。 もしくは、 公開鍵データベース 4 1 ζには公開鍵に関する情報として公開鍵を識別す るためのシリアル番号等を登録しておき、 公開鍵管理機能 4 0 ζがこのシ リアル番号を公開鍵データベース 4 1 ζから取得したのち、 これをもとに チームデータリスト管理装置 3 ◦ ζの外部 （例えばインタ一ネッ ト上） に 登録されている公開鍵を別途取得してリ ス ト作成者確認機能 3 7 ζに渡す ように構成しても良い。 一方、 リ ス ト作成者確認機能 3 7 ζは、 コンピュータのディスプレイ上 に上述したようなメッセージを出す代わりに、 公開鍵管理機能 4 0 ζから 通知されるチームマスタの公開鍵に基づいて、 チームデータリス ト保管装 置 3 1 ζから転送されてくるチームマスタリス トに含まれているデジタル 署名を確認するようにして、 当該デジタル署名がチームマスタのものであ るか判断する。 こうすることで、 ュ一ザがディスプレイ上の表示をもとに 目視で確認することなくチームマスタの正当性を検証できるようになる。
〔チームマスタ変更時におけるチームマスタ確認の自動化〕
ところで、 図 7 3に示したように正規の手続きでチームマスタが例えば メンバ M X ζからメンバ Μ Κ ζに変更された場合には、 もはや旧管理者た るメンバ M X ζの公開鍵を使用することができなくなる。 そのため、 クラ イアント C L ζ側に登録されているチームマスタの公開鍵をユーザの介在 183 なしに自動的に変更してやる必要がある。 かかる変更処理を実現するため に、 最終的なチームマスタ リス ト 6 1 ζ (図 7 3参照） が作成されたのち (即ち、 ステップ S 5 1 ζの後） に以下の処理を行うことにすれば良い。 まず、 チームデータリス ト保管装置 3 1 ζでは権限確認機能 3 5 ζが旧 チームマスタ リス ト， 移行期のチームマスタ リス ト， 最終的なチームマス タリス ト （即ち、 チームマスタ リス ト 4 5 ζ， 5 7 ζ , 6 1 ζ ) をそれぞ れチームデータリス ト管理装置 3 0 ζに転送する。 チームデータリス ト管 理装置 3 0 ζにおいて、 リスト作成者確認機能 3 7 ζは、 公開鍵管理機能 4 0 ζを通じて公開鍵データべ一ス 4 1 ζにおいてチームマスタとしてメ ンバ M X ζが登録されていることを知る。 次に、 リス ト作成者確認機能 3 7 ζはチームデータリス ト保管装置 3 1 ζから転送されてきた 3つのリス トから、 旧管理者たるメンバ M X ζが正規の手続きに則って新管理者たる メンバ Μ Κ ζに権限委譲したことを確認することができる。 とレ、うのも、 チームマスタリス ト 4 5 ζ， 5 7 ζ , 6 1 ζ にそれぞれ登 録されているチームマスタはメンバ M X ζ→メンバ Μ Κ ζ→メンバ Μ Κ ζ と遷移しており、 その一方で、 これらリ ス トに添付されているデジタル署 名はそれぞれメンバ M X ζ→メンバ Μ Χ ζ—メンバ Μ Κ ζ と遷移している。 こうしたことから、 リス ト作成者確認機能 3 7 ζは公開鍵管理機能 4 0 ζ を介在して公開鍵データベース 4 1 ζにチームマスタとして登録されてい る者の公開鍵をメンバ M X ζのものからメンバ Μ Κ ζのものに変更する。 なお、 チームマスタの変更はそれほど煩雑に生じることはないことから、 この変更処理を行うにあたってユーザに確認を求めるようにしても良い。 また、 チームマスタを確認するための情報としては公開鍵以外にも様々な 情報を利用できるのはもちろんである。 184
なお、 上述した実施形態では、 メ ンバリス トを一つだけ設けていたが、 複数のメンバリス トを用いるようにした場合であっても、 チームマスタ自 身の変更や複数のチームマスタによるリ ソース管理を実現することができ る。 例えば、 各メンバの持つ権限に応じてメンバリス トを 2つ以上のメン バリス トに細分化させることが考えられる。 このようにすると、 各メンバ リス トに属するメ ンバの共有する情報をメンバリストに応じて異なるもの にすることが可能となる。 以上の通り、 チームデータリス ト管理プログラムを記録した記録媒体に おいて
、 チームデータリ ス ト管理プログラムは、 （ 1 ) 変更指示を行う指示者の 本人識別 ·認証を行うための情報を所定の要求先に通知して、 資源を互い に共有するメンバで構成されるチームに関わる情報と該情報の管理権限を 有するマスタのデジタル署名とが含まれ、 チームに属するメンバの権限に 応じて用意されたチームデータリス トを前記要求先から取得する処理と、
( 2 ) 取得された該チームデータリ ス トの内容に基づいて、 権限を持つマ スタが前記チームデータリス トを作成したか否かを確認する確認処理と、
( 3 ) 該確認処理によって権限を持つマスタの作成であることが確認され た前記チームデータリス 卜に対して前記変更指示に応じた変更を加えるリ ス ト変更処理と、 （4 ) 前記指示者のデジタル署名を作成し、 前記リ ス ト 変更処理で変更されたチームデータリス トに該デジタル署名を添付して前 記要求先に送るデジタル署名処理とをコンピュータに実行させる.。
また、 上述のチームデータリス ト管理プログラムは、 前記メンバに関す るメンバ情報及び前記マスタのデジタル署名が少なく とも含まれた 1っ以 上のメンバリ ス トと、 前記マスタの権限を示すマスタ情報及び前記マスタ 185 のデジタル署名が少なく とも含まれたマスタリス 卜を前記チームデータリ ストとして用いている。
また、 上述のチームデータリス ト管理プログラムは、 前記マスタには前 記マスタ リス トの変更権限を有するチームマスタが含まれ、 前記変更指示 は前記チームマスタの変更指示であって、 前記確認処理は、 前記変更され たメンバリス 卜及びマスタ リス トを前記要求先に送出する処理と、 該処理 に対応して前記要求先から返送される移行期のメンバリスト及び移行期の マスタ リス トに含まれる前記マスタのデジタル署名を確認する処理とをさ らに有し、 前記デジタル署名処理は、 前記変更指示で指定された変更後の チームマスタのデジタル署名を作成する処理と、 前記移行期のメンバリス ト及び移行期のマスタ リ ス トに該デジタル署名を付与した新メンバリ ス ト 及び新マスタリス トを前記要求先に送り返す処理とをさらに有するもので あっても良い。
また、 上述のチームデータリス ト管理プログラムは、 前記チームマスタ の本人識別を行うための識別情報を所定の場所から取得して予め登録して おく処理と、 前記チームマスタの識別情報並びに前記要求先から送られて くる前記メンバリス 卜及び前記マスタリス 卜に含まれる前記マスタのデジ タル署名に基づいて、 該マスタのデジタル署名が前記チームマスタのデジ タル署名であるか否かを確認する処理とをさらにコンピュータに実行させ るものであっても良い。
また、 上述のチームデータリス ト管理プログラムは、 前記変更指示に際 して取得したマスタ リス ト， 前記移行期のマスタ リス ト及び前記新マスタ リス トの内容の変遷に基づいて、 前記チームマスタが正規の手続きを経て 変更されたことを確認する処理と、 該変更が確認された場合に、 前記変更 指示で指定された変更後のチームマスタの識別情報を取得し、 該識別情報 により前記予め登録された変更前のチームマスタの識別情報を更新する処 186 理とをさらにコンピュータに実行させるものであっても良い。 一方、チームデ一タリス ト保管プログラムを記録した記録媒体において、 チームデ一タリス ト保管プログラムは、 （ 1 ) 資源を互いに共有するメン バで構成されるチームに関わる情報と該情報の管理権限を有するマスタの デジタル署名が含まれ、 チームに属するメンバの権限に応じて用意される チームデータリス トを予め記憶しておく記憶処理と、 （2 ) 所定の要求元 から参照要求が送られた場合に、 前記チームデータリス ト及び該要求を行 つた指示者の本人識別 ·認証を行うための情報に基づいて前記指示者が前 記要求の権限を有するか否かを判断して、 前記指示者が前記要求の権限を 有する場合にだけ前記要求元へ前記チームデータリス トを送出する処理と、 ( 3 ) 前記要求元から更新要求が送られた場合に、 該要求元から送られて くるチームデータリス トの内容に基づいて該チームデータリス トの正当性 を確認し、 該正当性が確認された場合にのみ、 記憶されている前記チーム データリストを更新する権限確認処理とをコンピュータに実行させる。 また、 上述のチームデータリス ト保管プログラムにおいて、 前記記憶処 理は、 前記メンバに関するメンバ情報と前記マスタのデジタル署名が少な くとも含まれた 1つ以上のメンバリス トを予め記憶しておく処理と、 前記 マスタの権限を示すマスタ情報及び前記マスタのデジタル署名が少なく と も含まれたマスタリス トを予め記憶しておく処理とをコンピュータに実行 させるものであっても良い。 また、 上述のチ一ムデ一タリス ト保管プログラムは、 前記マスタには前 記マスタリス トの変更権限を有するチームマスタが含まれ、 前記権限確認 処理は、 前記要求元から前記指示者による前記チームマスタの変更指示が 通知された場合に、 該変更前のマスタリス トを旧マスタリス トとして保存 187 する処理と、 前記要求元からの要求によって前記マスタ リス ト及び前記メ ンバリス トを前記要求元に送出し、 これらリ ス トのうち、 前記チームマス タに関する情報の変更された移行期のマスタリス ト及び移行期のメ ンバリ ストを前記要求元から受け取って前記チームマスタの変更を検出する処理 と、 該チームマスタの変更が検出された場合に、 前記移行期のマスタリス ト， 前記移行期のメンバリス ト及び前記旧マスタ リス トに基づいて、 前記 チームマスタの変更の正当性を確認する処理と、 該変更の正当性が確認さ れた場合に、 前記移行期のマスタ リスト及び移行期のメンバリス トを前記 要求元に送出し、 これらリス 卜に対して前記変更指示で指定された変更後 のチームマスタのデジタル署名が添付された新マスタリスト及び新メンバ リス トを前記要求元から受け取って正当性を確認し、 該正当性が確認され た場合にのみ記憶されている前記メンバリス ト及び記憶されている前記マ スタ リ ス トを更新する処理とをさらにコンピュータに実行させるものであ つても良レ、。 以上説明したように、 第 6の実施形態の発明には、 以下のような効果が ある。
本発明では、 正当な権限を持つマスタからの変更指示に応じて、 サーバ 等に保管されているマスタ リス ト及びメンバリス ト等のチームデ一タリス トを取得し、 これらリス 卜が権限を持つマスタによって正当に作成された ことを確認した後に、 これらリス トに変更を加えて要求先へ返すようにし ている。 こ う したことから、 マスタ以外の一般のメンバ， サーバの管理者， クラッカ等の正当な権限を持たない者がチームデータリ ストを不正に操作 したことを検知できる。
また、 本発明では、 チームマスタ自身がチームマスタの変更を行うこと ができるため、 チームデータリス 卜が保管されているサーバ等の管理者を 188 介在させることなくチームマスタの権限委譲を実現できる。 しかも、 複数 の管理者でチームデータリストを管理してゆく仕組みを実現できるため、 少数の管理者に負担が集中してしまうのを緩和させることが可能となる。 また、 本発明では、 チームデータリス トに対してマスタのデジタル署名 を含ませているため、 チームデータリス トに対してなされた改竄等の不正 な行為を検出することが可能となる。
また、 本発明では、 チームデータリス トの参照要求や更新要求がなされ た場合に、 これらの要求を行った指示者が権限を持つ者であるのかどうか の権限確認を実施するようにしているので、 権限を持たない者による不正 な行為を未然に防止することができる。
また、 本発明では、 公開鍵などのチームマスタ本人を識別 '認証するた めの情報を予め登録しておき、 チームデータリス ト中のマスタのデジタル 署名と照合するほか、 チームマスタが変更された場合にはかかる変更を検 出して、 登録されているチームマスタの公開鍵等を適宜更新するようにし ている。 こうしたことから、 チームデ一タリス トを操作する度にユーザ自 身がチームマスタを目視で確認するなどの煩わしい作業が必要なくなり、 自動的にチームマスタの承認を行ってゆく ことができる。 なお、 ここでいう 「コンピュータシステム」 とは、 O Sや周辺機器等の ハードウェアを含むものとする。 また、 「コンピュータ読み取り可能な記 録媒体」 とは、 フロ ッピーディスク、 光磁気ディスク、 R O M、 C D - R O M等の可般媒体、 コンピュータシステムに内蔵されるハ一ドディスク等 の記憶装置のことをいう。 さらに「コンピュータ読み取り可能な記録媒体」 とは、 インタ一ネッ 卜等のネッ トワークや電話回線等の通信回線を介して プログラムを送信する場合の通信線のように、 短時間の間、 動的にプログ ラムを保持するもの （伝送媒体、 伝送波）、 その場合のサーバゃクライア 189 ントとなるコンピュータシステム内部の揮発性メモリのように、 一定時間 プログラムを保持しているものも含むものとする。また上記プログラムは、 前述した機能の一部を実現するためのものであっても良く、 さらに前述し た機能をコンピュータシステムにすでに記録されているプログラムとの組 み合わせで実現できるものであっても良い。 最後に、 これらの実施の形態で必要な特徴のすべての組み合わせを列挙 しているものではない。 また、 上記で説明した組み合わせ以外の組み合わ せも発明になり得る。

Claims

190 請求の範囲
1 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能な情報共有システムであって、
少なく とも複数のメンバーでアクセス可能で、 少なく ともチームマスタ 一のデジタル署名、 メンバ一公開鍵情報を含むメンバ一リス ト、 暗号化鍵 情報を含む共通鍵リスト、 および暗号化データを保管可能な情報保管装置 と、
情報を見てもよい少なく とも一のメンバーの公開鍵を記憶する記憶部と、 情報を暗号化するための共通鍵を用いる上記共通鍵暗号化方式に基づいて 入力情報を暗号化して暗号化データを生成する暗号化部と、 暗号化に用い た共通鍵を、 上記記憶部に記憶され指定された公開鍵で暗号化し、 暗号化 鍵を生成する暗号化鍵生成部と、 上記複数の暗号化鍵および暗号化データ を上記情報保管装置に転送する転送部と、 上記情報保管装置からメンバ一 リス 卜を取得して、 当該メンバ一リス 卜のチームマスタ一のデジタル署名 が指定されたデジタル署名と一致するか否かを判断し、 一致する場合にの み追加するメンバーの公開鍵の登録または脱会するメンバーの公開鍵の削 除を行い、 追加登録または削除の場合、 少なく ともチームマスターのデジ タル署名、 メンバ一公開鍵情報を含む新メンバーリス トを作成して上記情 報保管装置に転送するリス ト管理部と、 上記情報保管装置から所望の暗号 化鍵情報および暗号化データを取得して、 この暗号化鍵情報から共通鍵を 復号し、 復号した共通鍵で取得した暗号化データを復号する複号化部とを 有する暗号化複号化装置と
を備えた情報共有システム。
2 . 前記情報保管装置および前記暗号化複合化装置は、 送信側から受 信側へ情報またはデータが送信された場合、 前記送信側から情報またはデ 191 ータの送信が行われたことを受信側に対し通知する送信通知と、 受信側が 確実に前記情報を受信したことを送信側に対し通知する受信通知とを行う 送受信通知部を
さらに有する請求項 1記載の情報共有システム。
3 . 上記暗号化復号化装置は、 上記情報保管装置の共通鍵リス トから 少なく とも暗号化鍵情報を取得し、この暗号化鍵情報から共通鍵を復号し、 復号した共通鍵で上記共通鍵暗号化方式に基づいて入力情報を暗号化して 暗号化データを生成し、 上記転送部に出力する出力部を
さらに有する請求項 1記載の情報共有システム。
4 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメンバ一 でアクセス可能で、 少なく ともチームマスタ一のデジタル署名、 メンバ一 公開鍵情報を含むメ ンバ一リス ト、 暗号化鍵情報を含む共通鍵リス ト、 お よび暗号化データが保管されている情報共有システムの情報処理方法であ つて、
グループに属するメンバ一を追加登録または削除する場合、 上記情報保 管装置からメンバーリス トを取得する工程と、
当該メンバ一リス 卜のチームマスターのデジタル署名が指定されたデジ タル署名と一致するか否かを判断する工程と、
一致する場合にのみ、 少なく ともチームマスタ一のデジタル署名、 メン バー公開鍵情報を含む新メンバ一リストを作成する工程と、
作成したメンバ一リス トを上記情報保管装置に転送する工程と を有する情報共有システムの情報処理方法。
5 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメンバー でアクセス可能で、 少なく ともチームマスターのデジタル署名、 メンバ一 192 公開鍵情報を含むメンバ一リス ト、 暗号化鍵情報を含む共通鍵リス ト、 お よび暗号化データが保管されている情報共有システムの情報処理方法であ つて、
グループに属するメンバーで利用する共通鍵を登録する場合、 上記情報 保管装置からメンバ一リス トを取得する工程と、
当該メンパーリス トのチームマスターのデジタル署名が指定されたデジ タル署名と一致するか否かを判断する工程と、
一致する場合にのみ、 上記指定されている公開鍵を用いて登録すべき共 通鍵を暗号化する工程と、
暗号化された共通鍵を上記情報保管装置に転送する工程と
を有する情報共有システムの情報処理方法。
6 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメンバー でアクセス可能で、 少なく ともチームマスタ一のデジタル署名、 メンバ一 公開鍵情報を含むメンバーリス ト、 暗号化鍵情報を含む共通鍵リス ト、 お よび暗号化データが保管されている情報共有システムの情報処理方法であ つて、
送信側から受信側へ情報またはデータが送信された場合、 前記送信側か ら情報またはデータの送信が行われたことを受信側に対し通知する送信通 知と、 受信側が確実に前記情報を受信したことを送信側に対し通知する受 信通知を行う工程を
さらに有する請求項 5記載の情報共有システムの情報処理方法。
7 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメンバー でアクセス可能で、 少なく ともチームマスタ一のデジタル署名、 メンバ一 公開鍵情報を含むメンバ一リス ト、 暗号化鍵情報を含む共通鍵リス ト、 お 193 よび暗号化データが保管されている情報共有システムの情報処理方法であ つて、
上記情報保管装置の共通鍵リ ス トから少なく とも暗号化鍵情報を取得す る工程と、
この暗号化鍵情報から共通鍵を復号する工程と、
復号した共通鍵で上記共通鍵暗号化方式に基づいて入力情報を暗号化し て暗号化データを生成する工程と、
暗号化されたデータを上記情報保管装置に転送する工程と
を有する情報共有システムの情報処理方法。
8 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメ ンバー でアクセス可能で、 少なく ともチームマスタ一のデジタル署名、 メンバー 公開鍵情報を含むメンバーリス ト、 暗号化鍵情報を含む共通鍵リス ト、 お よび暗号化データが保管されている情報共有システムの情報処理方法であ つて、
送信側から受信側へ情報またはデータが送信された場合、 前記送信側か ら情報またはデータの送信が行われたことを受信側に対し通知する送信通 知と、 受信側が確実に前記情報を受信したことを送信側に対し通知する受 信通知を行う工程を
さらに有する請求項 7記載の情報共有システムの情報処理方法。
9 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく ともグ ループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメ ンバー でアクセス可能で、 少なく ともチームマスタ一のデジタル署名、 メンバー 公開鍵情報を含むメ ンバーリス ト、 暗号化鍵情報を含む共通鍵リス ト、 お よび暗号化データが保管されている情報共有システムの情報処理方法であ つて、 194 上記情報保管装置から所望の暗号化鍵情報および暗号化データを取得す る工程と、
この暗号化鍵情報から共通鍵を復号する工程と、
復号した共通鍵で取得した暗号化データを復号する工程と
を有する情報共有システムの情報処理方法。
1 0 . 共通鍵暗号化方式および公開鍵暗号方式を採用し、 少なく とも グループで共通鍵を共有可能で、 情報保管装置に少なく とも複数のメンバ —でアクセス可能で、 少なく ともチームマスターのデジタル署名、 メンバ —公開鍵情報を含むメンパーリ ス ト、 暗号化鍵情報を含む共通鍵リスト、 および暗号化データが保管されている情報共有システムの情報処理方法で めって、
送信側から受信側へ情報またはデータが送信された場合、 前記送信側か ら情報またはデータの送信が行われたことを受信側に対し通知する送信通 知と、 受信側が確実に前記情報を受信したことを送信側に対し通知する受 信通知を行う工程を
さらに有する請求項 9記載の情報共有システムの情報処理方法。
1 1 . 少なく とも複数のメンバ一でアクセス可能で、 少なく ともチ一 ムマスタ一のデジタル署名、 メンバ一公開鍵情報を含むメンバ一リス ト、 暗号化鍵情報を含む共通鍵リ ス ト、 および暗号化データが保管されている 情報保管装置からメンパーリス トを取得する工程と、
当該メンバ一リス トのチームマスタ一のデジタル署名が指定されたデジ タル署名と一致するか否かを判断する工程と、
一致する場合にのみ、 少なく ともチームマスターのデジタル署名、 メン バ一公開鍵情報を含む新メンバ一リ ストを作成する工程と、
作成したメンバーリス トを上記情報保管装置に転送する工程と をコンピュータに実行させるプログラムを記録したコンピュータ読み取 195 り可能な記録媒体。
1 2 . 少なく とも複数のメンバ一でアクセス可能で、 少なく ともチー ムマスタ一のデジタル署名、 メンバ一公開鍵情報を含むメンバーリスト、 暗号化鍵情報を含む共通鍵リス ト、 および暗号化データが保管されている 情報保管装置からメンバ一リス トを取得する工程と、
当該メンパーリス トのチームマスタ一のデジタル署名が指定されたデジ タル署名と一致するか否かを判断する工程と、
一致する場合にのみ、 上記指定されている公開鍵を用いて登録すべき共 通鍵を暗号化する工程と、
暗号化された共通鍵を上記情報保管装置に転送する工程と
をコンピュータに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体。
1 3 . 送信側から受信側へ情報またはデータが送信された場合、 前記 送信側から情報またはデータの送信が行われたことを受信側に対し通知す る送信通知と、 受信側が確実に前記情報を受信したことを送信側に対し通 知する受信通知を行う工程を
さらにコンピュータに実行させるプログラムを記録した請求項 1 2に記 載のコンピュータ読み取り可能な記録媒体。
1 4 . 少なく とも複数のメンバーでアクセス可能で、 少なく ともチ一 ムマスターのデジタル署名、 メンバ一公開鍵情報を含むメンバ一リスト、 暗号化鍵情報を含む共通鍵リス ト、 および暗号化データが保管されている 情報保管装置の共通鍵リス 卜から少なく とも暗号化鍵情報を取得する工程 と、
この暗号化鍵情報から共通鍵を復号する工程と、
復号した共通鍵で上記共通鍵暗号化方式に基づいて入力情報を暗号化し て暗号化データを生成する工程と、 196 暗号化されたデータを上記情報保管装置に転送する工程と
をコンピュータに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体。
1 5 . 送信側から受信側へ情報またはデータが送信された場合、 前記 送信側から情報またはデータの送信が行われたことを受信側に対し通知す る送信通知と、 受信側が確実に前記情報を受信したことを送信側に対し通 知する受信通知を行う工程を
さらにコンピュータに実行させるプログラムを記録した請求項 1 4に記 載のコンピュータ読み取り可能な記録媒体 c
1 6 . 少なく ともチームマスタ一のデジタル署名、 メンバー公開鍵情 報を含むメンバーリス ト、 暗号化鍵情報を含む共通鍵リス ト、 および暗号 化データが保管されている情報保管装置から所望の暗号化鍵情報および喑 号化データを取得する工程と、
この暗号化鍵情報から共通鍵を復号する工程と、
復号した共通鍵で取得した暗号化データを復号する工程と
をコンビュ一タに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体。
1 7 . 送信側から受信側へ情報またはデータが送信された場合、 前記 送信側から情報またはデータの送信が行われたことを受信側に対し通知す る送信通知と、 受信側が確実に前記情報を受信したことを送信側に対し通 知する受信通知を行う工程を
さらにコンピュータに実行させるプログラムを記録した請求項 1 6に記 載のコンピュータ読み取り可能な記録媒体。
1 8 . 少なく とも複数のメンバ一でアクセス可能で、 少なく ともメン バ一公開鍵情報を含むメンバ一リス ト、暗号化鍵情報を含む共通鍵リスト、 および暗号化データを保管可能で、 共通鍵暗号化方式および公開鍵暗号方 197 式を採用し、 少なく ともグループで共通鍵を共有可能なシステムに適用可 能な情報保管装置であって、
メンバーリスト変更要求に応答して上記メンバーリス 卜を変更可能なメ ンバ一リス ト管理部と、
共通鍵の登録要求に応答して上記共通鍵リス トに要求のあった共通鍵を その暗号化鍵情報を含めて登録し、 共通鍵要求に応答して、 要求時点、 特 定グループでの情報共有に最適な共通鍵を選択して、 要求先に転送する共 通鍵管理部と、
暗号化データの登録要求に応答して暗号化データを当該データの暗号化 に用いられた共通鍵情報とともに保管し、 暗号化データの取得要求に応答 して該当する保管暗号化データおよび共通鍵情報を要求先に転送する暗号 化データ管理部と
を有する情報保管装置。
1 9 . 上記メンバーリス ト管理部および共通鍵管理部は、 特定グルー プへのメンバ一の新規登録時には、 登録時点よりも前にグループで共有さ れていた情報を読めるように、 上記メンバ一リス トおよび共通鍵リス トを 変更する
請求項 1 8記載の情報保管装置。
2 0 . 上記メンバーリス ト管理部および共通鍵管理部は、 特定グルー プへのメンバーの削除時には、 削除されたメンバ一が当該削除以後グルー プで共有されていた情報を読めないように、 上記メンバ一リス トおよび共 通鍵リストを変更する
請求項 1 8記載の情報保管装置。
2 1 . 少なく とも複数のメンバーでアクセス可能で、 少なく ともメン バ一公開鍵情報を含むメ ンバーリス ト、暗号化鍵情報を含む共通鍵リスト、 および暗号化データを保管可能で、 共通鍵暗号化方式および公開鍵暗号方 198 式を採用し、 少なく ともグループで共通鍵を共有可能なシステムに適用可 能な情報保管装置の情報処理方法であって、
メンバ一リスト変更要求に応答して上記メンバ一リス トを変更する工程 と、
共通鍵の登録要求に応答して上記共通鍵リス 卜に要求のあった共通鍵を その暗号化鍵情報を含めて登録する工程と、
共通鍵要求に応答して、 要求時点、 特定グループでの情報共有に最適な 共通鍵を選択して、 要求先に転送する工程と、
暗号化データの登録要求に応答して暗号化データを当該データの暗号化 に用いられた共通鍵情報とともに保管する工程と、
暗号化データの取得要求に応答して該当する保管暗号化データおよび共 通鍵情報を要求先に転送する工程と
を有する情報保管装置の情報処理方法。
2 2 . 特定グループへのメンバ一の新規登録時には、 登録時点よりも 前にグループで共有されていた情報を読めるように、 上記メンバ一リス ト および共通鍵リス トを変更する工程
をさらに有する請求項 2 1記載の情報保管装置の情報処理方法。
2 3 . 特定グループへのメンバ一の削除時には、 削除されたメンバー が当該削除以後グループで共有されていた情報を読めないように、 上記メ ンバ一リス トおよび共通鍵リス トを変更する工程
をさらに有する請求項 2 1記載の情報保管装置の情報処理方法。
2 4 . メンパーリス ト変更要求に応答して上記メンパーリ ス トを変更 する工程と、
共通鍵の登録要求に応答して上記共通鍵リス 卜に要求のあった共通鍵を その暗号化鍵情報を含めて登録する工程と、
共通鍵要求に応答して、 要求時点、 特定グループでの情報共有に最適な 199 共通鍵を選択して、 要求先に転送する工程と、
暗号化データの登録要求に応答して暗号化データを当該データの暗号化 に用いられた共通鍵情報とともに保管する工程と、
暗号化データの取得要求に応答して該当する保管暗号化データおよび共 通鍵情報を要求先に転送する工程と
をコンピュータに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体。
2 5 . メンバ一リス ト変更要求に応答して上記メンパーリストを変更 する工程と、
共通鍵の登録要求に応答して上記共通鍵リス トに要求のあった共通鍵を その暗号化鍵情報を含めて登録する工程と、
共通鍵要求に応答して、 要求時点、 特定グループでの情報共有に最適な 共通鍵を選択して、 要求先に転送する工程と、
暗号化データの登録要求に応答して暗号化データを当該データの暗号化 に用いられた共通鍵情報とともに保管する工程と、
暗号化データの取得要求に応答して該当する保管暗号化データおよび共 通鍵情報を要求先に転送する工程と、
特定グループへのメンバーの新規登録時には、 登録時点よりも前にダル —プで共有されていた情報を読めるように、 上記メンバーリス トおよび共 通鍵リス トを変更する工程と
をコンピュータに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体。
2 6 . メンバ一リス ト変更要求に応答して上記メンバ一リ ストを変更 する工程と、
共通鍵の登録要求に応答して上記共通鍵リス 卜に要求のあった共通鍵を その暗号化鍵情報を含めて登録する工程と、 200 共通鍵要求に応答して、 要求時点、 特定グループでの情報共有に最適な 共通鍵を選択して、 要求先に転送する工程と、
暗号化デ一タの登録要求に応答して暗号化データを当該データの暗号化 に用いられた共通鍵情報とともに保管する工程と、
暗号化データの取得要求に応答して該当する保管暗号化データおよび共 通鍵情報を要求先に転送する工程と、
特定グループへのメンバーの削除時には、 削除されたメンバ一が当該削 除以後グループで共有されていた情報を読めないように、 上記メンバ一リ ストおよび共通鍵リス トを変更する工程と
をコンピュータに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体。
2 7 . メンバ一リス ト変更要求に応答して上記メンパーリストを変更 する工程と、
共通鍵の登録要求に応答して上記共通鍵リス 卜に要求のあった共通鍵を その暗号化鍵情報を含めて登録する工程と、
共通鍵要求に応答して、 要求時点、 特定グループでの情報共有に最適な 共通鍵を選択して、 要求先に転送する工程と、
暗号化データの登録要求に応答して暗号化データを当該データの暗号化 に用いられた共通鍵情報とともに保管する工程と、
暗号化データの取得要求に応答して該当する保管暗号化データおよび共 通鍵情報を要求先に転送する工程と、
特定グループへのメンバ一の新規登録時には、 登録時点よりも前にグル —プで共有されていた情報を読めるように、 上記メンバーリ ス トおよび共 通鍵リストを変更する工程と
特定グループへのメンバ一の削除時には、 削除されたメンバーが当該削 除以後グループで共有されていた情報を読めないように、 上記メンバ一リ 201 ストおよび共通鍵リス トを変更する工程と
をコンピュータに実行させるプログラムを記録したコンピュータ読み取 り可能な記録媒体.。
2 8 . 送信者側に設置された送信者側端末と、 前記送信者側端末とネ ッ トワークを介して接続され受信者側に設置された受信者側端末とを有し、 該送信者側端末と受信者側端末との間で情報の送受信を行い、 該情報の改 竄を検知する情報改竄検知装置において、
前記受信者側端末が前記情報を受信したことを確認した旨を表す受信内 容確認情報を作成する受信内容確認情報作成部と、
前記受信内容確認情報を前記ネッ トワークを介して送信する送信部と、 前記ネッ トワークを介して前記受信内容確認情報を受信する受信部と、 前記送信者側端末から送信される前記情報と前記受信内容確認情報とを 比較し
、 この比較結果に基づいて改竄を検知する改竄検知部と
を具備する情報改竄検知装置。
2 9 . 前記受信内容確認情報作成部は、 前記受信者側端末により受信 された前記情報の全部または一部、 受信した該情報または一部をハッシュ 関数で圧縮したメッセージダイジェスト、 送信者に関する送信者情報、 受 信者に関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組 み合わせた情報に基づいて前記受信内容確認情報を作成する請求項 2 8に 記載の情報改竄検知装置。
3 0 . 前記受信内容確認情報作成部は、 前記受信者側端末により受信 された前記情報の全部または一部、 受信した該情報または一部をハッシュ 関数で圧縮したメッセージダイジェスト、 送信者に関する送信者情報、 受 信者に関する受信者情報、 通信情報のうち、 いずれか 1 つ、 または複数組 み合わせた情報をハッシュ関数で圧縮したメッセ一ジダイジエス 卜に基づ 202 いて前記受信内容確認情報を作成する請求項 2 8に記載の情報改竄検知装 置。
3 1 . 前記受信内容確認情報作成部は、 前記受信者側端末により受信 された前記情報の全部または一部、 受信した該情報または一部をハッシュ 関数で圧縮したメッセ一ジダイジ-スト、 送信者に関する送信者情報、 受 信者に関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組 み合わせた情報に対してデジタル署名したものを前記受信内容確認情報と して作成する請求項 2 8に記載の情報改竄検知装置。
3 2 . 前記受信内容確認情報作成部は、 前記受信者側端末により受信 された前記情報の全部または一部、 受信した該情報または一部をハッシュ 関数で圧縮したメッセージダイジェスト、 送信者に関する送信者情報、 受 信者に関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組 み合わせた情報を作成し、
該組み合わせた情報をハッシュ関数で圧縮したメッセージダイジエスト、 および該組み合わせた情報に対してデジタル署名をしたものを作成し、 前記組み合わせた情報、 前記メ ッセージダイジェス ト、 デジタル署名し たもののうちいずれか 2つ以上の情報を組み合わせたものを前記受信内容 確認情報として作成する請求項 2 8に記載の情報改竄検知装置。
3 3 . 送信者側に設置された送信者側端末と、 前記送信者側端末とネ ットワークを介して接続され受信者側に設置された受信者側端末とを有し、 該送信者側端末と受信者側端末との間で情報の送受信を行い、 該情報の改 竄を検知する情報改竄検知装置において、
前記受信者側端末が前記情報を受信したことを確認した旨を表す受信内 容確認情報を作成する受信内容確認情報作成部と、
前記受信内容確認情報を前記ネッ 卜ワークを介して送信する送信部と、 前記ネッ トヮ一クを介して前記受信内容確認情報を受信する受信部と、 203 前記送信者側端末から送信される前記情報と前記受信内容確認情報とを 比較し
、 この比較結果に基づいて改竄を検知する改竄検知部としてコンピュータ を機能させるための改竄検知プログラムを記録したコンピュータ読み取り 可能な記録媒体。
3 4 . 受信者側に設置された受信者側端末との間でネッ トワークを介 して情報の送受信を行い、 送信者側に設置された送信者側端末を有する情 報改竄検知装置において、
前記送信者側端末に設けられ、 前記受信者側端末が前記情報を受信した ことを確認した旨を表し、 かつ前記受信者側端末により生成された受信内 容確認情報を前記ネッ トワークを介して受信する受信部と、
前記送信者側端末に設けられ、 前記受信部により受信された前記受信内 容確認情報と前記送信者側端末から送信される前記情報とを比較し、 この 比較結果に基づいて改竄を検知する改竄検知部と
を具備する情報改竄検知装置。
3 5 . 前記受信内容確認情報は、 前記受信者側端末により受信された 前記情報の全部または一部、 受信した該情報または一部をハッシュ関数で 圧縮したメ ッセージダイジ ス ト、 送信者に関する送信者情報、 受信者に 関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組み合わ せた情報である請求項 3 4に記載の情報改竄検知装置。
3 6 . 前記受信内容確認情報は、 前記受信者側端末により受信された 前記情報の全部または一部、 受信した該情報または一部をハッシュ関数で 圧縮したメッセージダイジェス ト、 送信者に関する送信者情報、 受信者に 関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組み合わ せた情報をハッシュ関数で圧縮したメッセージダイジエス トである請求項 3 4に記載の情報改竄検知装置。 204
3 7 . 前記受信内容確認情報は、 前記受信者側端末により受信された 前記情報の全部または一部、 受信した該情報または一部をハッシュ関数で 圧縮したメッセージダイジェス ト、 送信者に関する送信者情報、 受信者に 関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組み合わ せた情報に対してデジタル署名したものである請求項 3 4に記載の情報改 竄検知装置。
3 8 . 前記受信内容確認情報は、 前記受信者側端末により受信された 前記情報の全部または一部、 受信した該情報または一部をハッシュ関数で 圧縮したメッセージダイジェス ト、 送信者に関する送信者情報、 受信者に 関する受信者情報、 通信情報のうち、 いずれか 1つ、 または複数組み合わ せた情報に基づいて作成され、
該組み合わせた情報をハッシュ関数で圧縮したメッセ一ジダイジエスト、 および該組み合わせた情報に対してデジタル署名をしたものに基づいて作 成され、
前記組み合わせた情報、 前記メッセージダイジェス ト、 デジタル署名し たもののうちいずれか 2つ以上の情報を組み合わせたものである請求項 3 4に記載の情報改竄検知装置。
3 9 . 受信者側に設置された受信者側端末との間でネッ トヮ一クを介 して情報の送受信を行い、 送信者側に設置された送信者側端末を有する情 報改竄検知装置において、
前記送信者側端末に設けられ、 前記受信者側端末が前記情報を受信した ことを確認した旨を表し、 かつ前記受信者側端末により生成され、 受信内 容確認情報を前記ネッ トワークを介して受信する受信部と、
前記送信者側端末に設けられ、 前記受信部により受信された前記受信内 容確認情報と前記送信者側端末から送信される前記情報とを比較し、 この 比較結果に基づいて改竄を検知する改竄検知部としてコンピュータを機能 205 させるための改竄検知プログラムを記録したコンピュータ読み取り可能な 記録媒体。
4 0 . 送信者側に設置された送信者側端末と、 前記送信者側端末とネ ッ トワークを介して接続され受信者側に設置された受信者側端末とを有し、 該送信者側端末と受信者側端末との間で情報の送受信を行い、 該情報の改 竄を検知する情報改竄検知装置において、
前記受信者側端末が前記情報を受信したことを確認した旨を表す受信内 容確認情報を作成する受信内容確認情報作成部と、
前記受信内容確認情報を前記ネッ トワークを介して送信する送信部と、 前記ネッ トワークを介して前記受信内容確認情報を受信する受信部と、 前記受信内容確認情報に基づいて、 送信者側端末が、 前記受信者側端末 の受信した情報を送信した旨を表す送信内容確認情報を作成し、 前記ネッ トヮ一クを介して前記受信側端末へ送信する送信内容確認情報作成部と、 前記送信内容確認情報作成部から送信された前記送信内容確認情報と、 前記受信側端末により受信された前記情報とを比較し、 この比較結果に基 づいて改竄を検知する改竄検知部と
を具備する情報改竄検知装置。
4 1 . 前記送信内容確認情報作成部は、 前記受信内容確認情報と該受 信内容確認情報の内容を確認した旨を表す確認情報のうち、いずれか 1つ、 または複数組み合わせた情報に基づいて前記送信内容確認情報を作成する 請求項 4 0に記載の情報改竄検知装置。
4 2 . 前記送信内容確認情報作成部は、 前記受信内容確認情報と前記 確認情報のうちいずれか 1つ、 または複数組み合わせた情報をハッシュ関 数で圧縮したメッセージダイジエス トに基づいて前記送信内容確認情報を 作成する請求項 4 0記載の情報改竄検知装置。
4 3 . 前記送信内容確認情報作成部は、 前記受信内容確認情報と前記確 206 認情報のうちいずれか 1つ、 または複数組み合わせた情報に対してデジタ ル署名したものを前記送信内容確認情報として作成する請求項 4 0に記載 の情報改竄検知装置。
4 4 . 前記送信内容確認情報作成部は、
前記受信内容確認情報と該受信内容確認情報の内容を確認した旨を表す 確認情報のうち、 いずれか 1つ、 または複数組み合わせた情報をハッシュ 関数で圧縮したメッセージダイジュストを前記送信内容確認情報として作 成し、
前記受信内容確認情報と前記確認情報のうちいずれか 1つ、 または複数 組み合わせた情報に対してデジタル署名したものを前記送信内容確認情報 として作成し、
前記組み合わせた情報、 前記メッセージダイジェス ト、 デジタル署名し たもののうちいずれか 2つ以上の情報を組み合わせたものに基づいて前記 送信内容確認情報を作成する請求項 4 0に記載の情報改竄検知装置。
4 5 . 送信者側に設置された送信者側端末との間でネッ トワークを介 して情報の送受信を行い、 受信者側に設置された受信者側端末を有する情 報改竄検知装置において、
前記受信者側端末に設けられ、 前記受信者側端末が前記情報を受信した ことを確認した旨を表す受信内容確認情報を作成する受信内容確認情報作 成部と、
前記受信者側端末に設けられ、 前記受信内容確認情報を前記ネッ トヮー クを介して送信する送信部と、
前記受信者側端末に設けられ、 前記受信内容確認情報に基づいて前記送 信者側端末により作成される、 前記受信者側端末の受信した情報を送信し た旨を表す送信内容確認情報を前記ネッ トワークを介して受信し、 該送信 内容確認情報と、 前記受信側端末により受信された前記情報とを比較し、 207 この比較結果に基づいて改竄を検知する改竄検知部と
を具備する情報改竄検知装置。
4 6 . 前記送信内容確認情報は、 前記受信内容確認情報と該受信内容 確認情報の内容を確認した旨を表す確認情報のうち、 いずれか 1つ、 また は複数組み合わせた情報である請求項 4 5に記載の情報改竄検知装置。
4 7 . 前記送信内容確認情報は、 前記受信内容確認情報と前記確認情報 のうちいずれか 1つ、 または複数組み合わせた情報をハッシュ関数で圧縮 したメ ッセ一ジダイジエス トである請求項 4 5に記載の情報改竄検知装置。
4 8 . 前記送信内容確認情報は、 前記受信内容確認情報と前記確認情 報のうちいずれか 1つ、 または複数組み合わせた情報に対してデジタル署 名したものである請求項 4 5に記載の情報改竄検知装置。
4 9 . 前記送信内容確認情報は、
前記受信内容確認情報と該受信内容確認情報の内容を確認した旨を表す 確認情報のうち、 いずれか 1つ、 または複数組み合わせた情報をハッシュ 関数で圧縮したメッセージダイジエストに基づいて作成され、
前記受信内容確認情報と前記確認情報のうちいずれか 1つ、 または複数 組み合わせた情報に対してデジタル署名したものに基づいて作成され、 前記組み合わせた情報、 前記メッセージダイジェス ト、 デジタル署名し たもののうちいずれか 2つ以上の情報を組み合わせたものである請求項 4 5に記載の情報改竄検知装置。
5 0 . 送信者側に設置された送信者側端末との間でネッ トワークを介 して情報の送受信を行い、 受信者側に設置された受信者側端末を有する情 報改竄検知装置において、
前記受信者側端末に設けられ、 前記受信者側端末が前記情報を受信した ことを確認した旨を表す受信内容確認情報を作成する受信内容確認情報作 成部と、 208 前記受信者側端末に設けられ、 前記受信内容確認情報を前記ネッ トヮ一 クを介して送信する送信部と、
前記受信者側端末に設けられ、 前記受信内容確認情報に基づいて前記送 信者側端末により作成される、 前記受信者側端末の受信した情報を送信し た旨を表す送信内容確認情報を前記ネッ トワークを介して受信し、 該送信 内容確認情報と、 前記受信側端末により受信された前記情報とを比較し、 この比較結果に基づいて改竄を検知する改竄検知部としてコンピュータを 機能させるための改竄検知プログラムを記録したコンピュータ読み取り可 能な記録媒体。
5 1 . 鍵暗号化部と、 暗号化部とからなる暗号化装置において、 前記鍵暗号化部は、
共通鍵暗号方式を利用して暗号化に用いる共通鍵を取得または生成する 共通鍵取得部と、
公開鍵暗号方式を利用して前記共通鍵を暗号化し暗号化鍵とする共通鍵 暗号化部と、
前記共通鍵より共通鍵改竄検出に利用する鍵情報を作成する第 1共通鍵 改竄検出情報作成部とからなり、
前記暗号化部は、
前記共通鍵を用いて平文を暗号化し暗号文とするデータ暗号化部と、 前記平文より第 1データ改竄検出情報を作成する第 1データ改竄検出情 報作成部とからなる暗号化装置。
5 2 . 前記共通鍵暗号化部は、 前記データ暗号化部により生成される 暗号文を共有する利用者毎に、 該利用者の公開鍵を用いて前記共通鍵を喑 号化し暗号化鍵を生成する請求項 5 1記載の暗号化装置。
5 3 . 前記暗号化装置は、 鍵復号化部をさらに備え、
前記鍵復号化部は、 公開鍵暗号方式を利用して前記暗号化鍵を複号化す 209 る共通鍵複号化部と、
前記暗号化鍵を復号化した共通鍵より共通鍵改竄検出情報を作成する第 2共通鍵改竄検出情報作成部と、
前記鍵情報と前記共通鍵改竄検出情報を用いて改竄検証する第 1改竄検 証部とからなり、
前記鍵複号化部は、 前記暗号化鍵を複号化し共通鍵を取得するとともに 改竄検証し、
前記暗号化部は、 前記共通鍵を用いて追加する平文をさらに暗号化する 請求項 5 1に記載の暗号化装置。
5 4 . 請求項 5 1.に記載の暗号化装置によって暗号化された前記暗号 化鍵と前記暗号文を復号化する、 鍵複号化部と復号化部とからなる復号化 装置において、
前記鍵複号化部は、 公開鍵暗号方式を利用して前記暗号化鍵を複号化す る共通鍵複号化部と、
前記暗号化鍵を復号化した共通鍵より共通鍵改竄検出情報を作成する第 2共通鍵改竄検出情報作成部と、
前記鍵情報と前記共通鍵改竄検出情報を用いて改竄検証する第 1改竄検 証部とカゝらなり、
前記復号化部は、 共通鍵暗号方式を利用して前記暗号文を復号化するデ —タ複号化部と、
前記暗号文を複号化した平文より第 2データ改竄検出情報を作成する第 2データ改竄検出情報作成部と、
前記第 1データ改竄検出情報と前記第 2データ改竄検出情報を用いて改 竄検証する第 2改竄検証部とからなる複号化装置。
5 5 . 前記共通鍵復号化部は、 暗号文を共有する利用者毎に対応する 暗号化鍵のすべてを復号化し、 210 前記共通鍵改竄検出情報作成部は、 複号化して得た共通鍵毎に前記共通 鍵改竄検出情報を作成し、
前記第 1改竄検証部は、 前記鍵情報と前記共通鍵改竄検出情報から改竄 検証を行なうとともに、 利用者に対応する共通鍵を判定する請求項 5 4に 記載の復号化装置。
5 6 . 請求項 5 1に記載の暗号化装置と、 請求項 5 4に記載の復号 化装置とから
構成される暗号化複号化装置。
5 7 . 共通鍵暗号方式を利用し、 暗号化に用いる共通鍵を取得または 生成する手順と、
公開鍵暗号方式を利用して前記共通鍵を暗号化し暗号化鍵とする手順と、 前記共通鍵より鍵情報を作成する手順と、
平文を共通鍵暗号方式を利用して暗号化し暗号文とする手順と、 前記平文より第 1データ改竄検出情報を作成する手順とを具備する暗号 化方法。
5 8 . 公開鍵暗号方式を利用して前記暗号化鍵を複号化する手順と、 前記暗号化鍵を複号化した共通鍵より共通鍵改竄検出情報を作成する手 順と、
前記鍵情報と前記共通鍵改竄検出情報とから改竄検証する手順と、 前記暗号文を共通鍵暗号方式で復号化する手順と、
前記暗号文を複号化した平文より第 2データ改竄検出情報を作成する手 順と、 前記第 1デ一タ改竄検出情報と前記第 2デ一タ改竄検出情報とか ら改竄検証する手順とを具備する復号化方法。
5 9 . 共通鍵暗号方式を利用し、 暗号化に用いる共通鍵を取得または 生成する手順と、
公開鍵暗号方式を利用して前記共通鍵を暗号化し暗号化鍵とする手順と、 211 前記共通鍵より鍵情報を作成する手順と、
平文を共通鍵暗号方式を利用して暗号化し暗号文とする手順と、 前記平文より第 1データ改竄検出情報を作成する手順とを
コンピュータに実行させるためのプログラムを記録したコンピュータ読 み取り可能な記録媒体。
6 0 . 公開鍵暗号方式を利用して前記暗号化鍵を複号化する手順と、 前記暗号化鍵を複号化した共通鍵より共通鍵改竄検出情報を作成する手 順と、
前記鍵情報と前記共通鍵改竄検出情報とから改竄検証する手順と、 前記暗号文を共通鍵暗号方式で復号化する手順と、
前記暗号文を複号化した平文より第 2データ改竄検出情報を作成する手 順と、 前記第 1データ改竄検出情報と前記第 2データ改竄検出情報とか ら改竄検証する手順とを
コンピュータに実行させるためのプログラムを記録したコンピュータ読 み取り可能な記録媒体。
6 1 . チームを階層化するためのチームデータリス 卜を管理するチー ムデ一タ リス ト管理装置であって、
所定の要求先に前記チームデータリス トの操作要求を行い、 該操作要求 に応じて、 操作対象のチームからル一トチームに至る各チームについて、 自チームの親チームを表す識別子及び前記親チームの管理者のデジタル署 名を含むオーソリティデータと、 自チームの管理下にあるサブチームの管 理権限者に関する管理者情報及び自チームの管理者であるチームマスタ又 は前記親チームの管理者のデジタル署名を含むォ一ソリティ リ ス トを有す るチームデータリストを前記要求先から取得し、 前記識別子を用いて取得 されたチ一ムを前記ル一トチームまで迪りながら各チームについて、 前記 チームデータリス 卜のデジタル署名が改竄されていないこと及び前記管理 212 者情報を用いて権限を持つ者によるデジタル署名であることを確認して、 ユーザによる前記ルートチームのチームマスタの承認を確認する正当性確 p| と、
該正当性確認部によって正当性が確認された前記チームデータリス トに 対して前記操作要求に応じた変更を加えるチームデータリスト変更部と、 前記操作要求を行った指示者のデジタル署名を作成し、 前記変更された チームデータリストに該デジタル署名を添付して前記要求先に送出するデ ジタル署名部と
を具備するチームデータリス ト管理装置。
6 2 . 前記管理者情報は、 前記チームマスタにより自チーム内のメ ン バから指名された者であって前記サブチームの管理権限を有する一人以上 のサブォ一ソリティと、 前記サブォ一ソリティの持つ権限に加えて前記サ ブオーソリティに対する管理権限を有する前記チームマスタとに関する情 報である請求項 6 1記載のチームデータリス ト管理装置。
6 3 . 前記ルートチームのチームマスタの本人識別を行うための識別 情報を所定の場所から取得して登録する登録部と、
予め登録されている前記識別情報を用いて、 前記要求先から送られてく る前記ルートチームのォ一ソリティデータのデジタル署名が前記チームマ スタのデジタル署名であることを確認するチームマスタ確認部とをさらに 有する請求項 6 1記載のチームデータリス ト管理装置。
6 4 . チームを階層化するためのチームデータリス トを保管するチー ムデータリス ト保管装置であって、
自チームの親チームを表す識別子及び前記親チームの管理者のデジタル 署名が含まれたオーソリティデータをチーム毎に記憶するオーソリティデ ―タ記憶部と、 自チームの管理下にあるサブチームの管理権限者に関す る管理者情報及び自チームの管理者であるチームマスタ又は前記親チーム 213 の管理者のデジタル署名が含まれたオーソリティ リス トをチーム毎に記憶 するオーソリティ リ スト記憶部と、
前記ォーソリティデータ及び前記オーソリティ リス 卜が少なく とも含ま れたチームデータリス トに対する所定の要求元からの操作要求について、 該操作要求の指示者が要求権限を持つことを前記管理者情報を用いて確認 するとともに、 参照要求或いは削除要求に対して要求されたチームデータ リス トを前記要求元へ返送し或いは削除し、 更新要求に対しては、 前記要 求元から送られるチームデータリス 卜のデジタル署名が権限を持つ者によ るデジタル署名であることを前記管理者情報を用いて確認し、 前記送られ たチームデータリス トで前記ォ一ソリティデータ記憶部及び前記ォ一ソリ ティリスト記憶部の記憶内容を更新する権限確認部と
を具備するチームデータリス ト保管装置。
6 5 . 前記管理者情報は、 前記チームマスタにより自チーム内のメ ン バから指名された者であって前記サブチームの管理権限を有する一人以上 のサブォーソリティと、 前記サブォ一ソリティの持つ権限に加えて前記サ ブオーソリティに対する管理権限を有する前記チームマスタとに関する情 報である請求項 6 4記載のチームデータリス ト保管装置。
6 6 . 要求元である請求項 6 1の何れかの項記載のチームデータリス ト管理装置と、
要求先である請求項 6 4記載のチームデータリスト保管装置とを有する チームデータリス ト処理システム。
6 7 . チ一ムを階層化するためのチームデータリス トを管理するチ一 ムデータリス ト管理プログラムを記録した記録媒体であって、
所定の要求先に前記チームデータリス トの操作要求を行う処理と、 前記操作要求に応じて、 操作対象のチームからルートチームに至る各チ —ムについて、 自チームの親チームを表す識別子及び前記親チームの管理 214 者のデジタル署名が含まれたォ一ソリティデータと、 自チームの管理下に あるサブチームの管理権限者に関する管理者情報及び自チームの管理者で あるチームマスタ又は前記親チームの管理者のデジタル署名が含まれたォ —ソリティリストを有するチームデータリス 卜を前記要求先から取得する 処理と、
前記識別子を用いて取得された各チームを前記ルートチームまで迪りな がら各チームについて、 前記チームデータリス トのデジタル署名が改竄さ れていないこと及び前記管理者情報を用いて権限を持つ者によるデジタル 署名であることを確認したのち、 ュ一ザによる前記ルートチームのチ一ム マスタの承認を確認する正当性確認処理と、
該正当性確認処理によって正当性が確認された前記チームデ一タリス ト に対して前記操作要求に応じた変更を加える変更処理と、
前記操作要求を行った指示者のデジタル署名を作成して、 前記変更処理 によって変更されたチームデータリストに該デジタル署名を添付して前記 要求先に送出する処理と
をコンピュータに実行させるためのチームデータリ ス ト管理プログラム を記録した記録媒体。
6 8 . チームを階層化するためのチームデータリス トを保管するチー ムデータリスト保管プログラムを記録した記録媒体であって、
自チームの親チームを表す識別子及び前記親チームの管理者のデジタル 署名が含まれたオーソリティデータをチーム毎に予め記憶しておく処理と、 自チームの管理下にあるサブチームの管理権限者に関する管理者情報及 び自チームの管理者であるチームマスタ又は前記親チームの管理者のデジ タル署名が含まれたォーソリティ リストをチーム毎に予め記憶しておく処 理と、
所定の要求元から前記ォーソリティデータ及び前記ォーソリティ リス ト 215 が少なく とも含まれたチームデータリス トに対する操作要求があつたとき に、 該操作要求の指示者が要求権限を持つことを前記管理者情報を用いて 確認するとともに、 該操作要求が参照要求或いは削除要求である場合は、 要求されたチームデータリストを前記要求元へ返送し或いは削除し、 該操 作要求が更新要求である場合は、 前記要求元から送られるチームデータリ ス トのデジタル署名が権限を持つ者によるデジタル署名であることを前記 管理者情報を用いて確認したのち、 前記送られたチームデータリストで記 憶されている前記ォーソリティデータ及び記憶されている前記ォ一ソリテ ィ リストを更新する権限確認処理と
をコンピュータに実行させるためのチームデータリス ト保管プログラム を記録した記録媒体。
6 9 . 送信する情報を暗号化した暗号化情報を含む暗号情報を作成す る暗号情報作成装置と、 同報通信の被配信メンバーの公開鍵が含まれるメ ンバ一リストを管理するメンバ一リスト管理装置と、 前記暗号化情報を復 号化する暗号情報復号化装置と、 前記暗号情報作成装置より送信された喑 号情報を受信し、 該喑号情報を前記メンバーリス トをもとに 1以上の前記 暗号情報復号化装置に配信する情報中継装置と、 からなる同報通信システ ムにおけるメンバ一リス ト管理装置であって、
同報通信を行う 1以上のメンバーの公開鍵を含むメンパーリストを作成 するリスト作成部と、
前記公開鍵を取得し保存する公開鍵管理部と
を備えるメンバ一リス ト管理装置。
7 0 . 前記メ ンバ一リ ス ト管理装置は、
ネッ トワークを介して端末から、 もしくは、 装置に接続された記憶媒体 から、 前記メンバ一リス トを取得し保存するリ ス ト取得保存部をさらに備 えた請求項 6 9記載のメンバ一リス ト管理装置。 216
7 1 . 前記メ ンバ一リス ト管理装置は、
前記メンバ一リス トをネッ トヮ一クを介して、 該ネッ トワークに接続さ れたデータべ一スまたは前記情報中継装置または前記メンバ一リス トに含 まれるメンバ一が利用する前記暗号情報作成装置ないし前記暗号情報復号 化装置に送信するリスト送信部をさらに備えた請求項 6 9に記載のメンバ 一リスト管理装置。
7 2 . 前記メンバ一リス ト管理装置は、
同報通信のメンバ一リス トへの加入要求項目を設定する加入要求項目設 定部と、
加入要求者により入力 ·転送された加入要求が、 前記加入要求項目を満 たし、 メンバーリス トへの加入を許可するか否かをを判断する加入許可判 断部と、
からなる加入要求受付部をさらに備える請求項 6 9に記載のメンバ一リ スト管理装置。
7 3 . 送信する情報を暗号化した暗号化情報を含む暗号情報を作成す る暗号情報作成装置と、 同報通信の被配信メンバ一の公開鍵が含まれるメ ンバ一リス トを管理するメンパーリス ト管理装置と、 前記暗号化情報を復 号化する暗号情報復号化装置と、 前記暗号情報作成装置より送信された喑 号情報を受信し、 該喑号情報を前記メンバーリス トをもとに 1以上の前記 暗号情報複号化装置に配信する情報中継装置と、 からなる同報通信システ ムにおける暗号情報作成装置であって、
ネッ トワークを介して端末から、 もしくは、 装置に接続された記憶媒体 から、 前記メンバ一リス トを取得し保存するリス ト取得保存部と、 同報通信文を取得し、 該同報通信文を前記メンバーリス卜に含まれる公 開鍵を用いて暗号化し暗号化情報とする暗号化部とを備えた暗号情報作成 217
7 4 . 前記暗号化部は、
前記同報通信文を共通鍵暗号方式で暗号化した暗号文を作成し、 前記共通鍵暗号方式で用いた共通鍵を、 前記メンバーリス トに含まれる 1以上の公開鍵を用いて公開鍵暗号方式で暗号化した 1以上の暗号化鍵を 作成し、 該暗号化鍵のうち、 被配信メンバーに対応する暗号化鍵を選択 するための鍵選択情報を作成し、
前記暗号情報として、 前記暗号文、 前記暗号化鍵、 および前記鍵選択情 報を出力する請求項 7 3に記載の暗号情報作成装置。
7 5 . 前記暗号化部は、
同報通信文が複数の構成要素で構成されている場合、 前記暗号化部は前 記同報通信文を構成する個々の構成要素毎に暗号化し前記暗号情報を作成 する請求項 7 3に記載の暗号情報作成装置。
7 6 . 前記暗号情報作成装置は、
同報通信文の送信先を検査し該送信先が前記情報中継装置でありかつ前 記リス 卜取得保存部からメンバーリストを取得できた場合、 該同報通信文 を前記暗号化部へ送る宛先検査部をさらに備えた請求項 7 3に記載の暗号 情報作成装置。
7 7 . 前記暗号情報作成装置は、
同報通信文が主構成要素と 1以上の従構成要素とからなる場合、 主構成 要素に対応する暗号情報に従構成要素に対応する暗号情報を参照可能とす る参照情報を含め前記情報中継装置へ送信し、 従構成要素に対応する暗号 情報をネッ トワーク上の情報保管装置に送信する複数パーツ送信部をさら に備えた請求項 7 3に記載の暗号情報作成装置。
7 8 . 送信する情報を暗号化した暗号化情報を含む暗号情報を作成す る暗号情報作成装置と、 同報通信の被配信メンバーの公開鍵が含まれるメ ンバーリス トを管理するメンバーリス ト管理装置と、 前記暗号化情報を復 218 号化する暗号情報複号化装置と、 前記暗号情報作成装置より送信された喑 号情報を受信し、 該喑号情報を前記メンバ一リス トをもとに 1以上の前記 暗号情報複号化装置に配信する情報中継装置と、 からなる同報通信システ ムにおける暗号情報複号化装置であって、
前記情報中継装置から転送された暗号情報を取得する暗号情報取得部と、 前記暗号情報に含まれる暗号化情報を復号化する復号化部とを備えた喑 号情報複号化装置。
7 9 . 前記複号化部は、
前記暗号情報に含まれる鍵選択情報を参照し復号化に利用する暗号化鍵 を選択する鍵選択部と、
公開鍵暗号方式を利用して前記選択した暗号化鍵を受信者の秘密鍵で復 号化し、 共通鍵を得る暗号化鍵復号化部と、
共通鍵暗号方式を利用して、 前記共通鍵を用いて前記暗号情報に含まれ る暗号化情報を複号化し、 平文の同報通信文を得る暗号文複号化部とから なる請求項 7 8に記載の暗号情報複号化装置。
8 0 . 前記暗号情報復号化装置は、
被配信メンバ一本人が受信したことを通知する受信通知を前記情報中継 装置に発信する受信通知発信部をさらに備える請求項 7 8に記載の暗号情 報復号化装置。
8 1 . 前記暗号情報複号化装置は、
同報通信文が主構成要素と 1以上の従構成要素とからなる場合、 従構成 要素に対応する暗号情報を参照可能とする参照情報を含む主構成要素に対 応する暗号情報を受信し、 前記参照情報をもとに従構成要素に対応する暗 号情報を受信する複数パーツ受信部をさらに備える請求項 7 8に記載の喑 号情報複号化装置。
8 2 . 前記暗号情報復号化装置は、 219 前記暗号情報作成装置における暗号情報作成時に用いられたメンバーリ ストと、 前記配信先リス トを作成するために利用したメンバ一リス トの同 一性の検証、 暗号情報の送信者がメンバ一リス 卜に含まれた者であるか かどうかの検証、 通信経路上で暗号情報が改竄されていないか検証する 完全性の検証、
転送されてきた情報の中に悪意あるプログラムゃデ一タ列が含まれてい るかどうかの検証、
転送されてきた暗号情報を参照して暗号情報作成装置で作成された複数 のパーツからなる暗号情報のうち、 一部が別の情報保管装置に転送されて いるかどうかの検証、
のいずれかもしくは組合わせによる前記検証を行なう同報通信安全性検 証部をさらに備える請求項 7 8に記載の暗号情報複号化装置。
8 3 . 前記暗号情報復号化装置は、
ネッ トヮ一クを介してメンパーリストを既に保存している装置から、 前 記メンバーリス トを取得し保存するリス ト取得保存部をさらに備えた請求 項 7 8に記載の暗号情報複号化装置。
8 4 . 送信する情報を暗号化した暗号化情報を含む暗号情報を作成す る暗号情報作成装置と、 同報通信の被配信メンバーの公開鍵が含まれるメ ンバーリストを管理するメンバーリスト管理装置と、 前記暗号化情報を復 号化する暗号情報複号化装置と、 前記暗号情報作成装置より送信された暗 号情報を受信し、 該喑号情報を前記メンバ一リス トをもとに 1以上の前記 暗号情報復号化装置に配信する情報中継装置と、 からなる同報通信システ ムにおける情報中継装置であって、
配信先リス トを管理する配信先リスト管理部と、
転送されてきた暗号情報を複製する情報複製部と、
複製された暗号情報を各被配信メンバーに配信する送信部とを備える情 220 報中継装置。
8 5 . 前記配信先リス ト管理部は、
必要なときに保存先からメンバ一リス トを取得可能であり、 転送された メンバ一リス トを保存するリス ト取得保存部と、
チームマスタ一から転送されてきたメンバ一リス 卜に含まれるメンバー と同じメ ンバ一に情報が配信されるように配信先リス トを変更する請求項 8 4に記載の情報中継装置。
8 6 . 前記情報中継装置は、
メンバ一リストに添付されたデジタル署名の正当性を確認する際に、 該 対応テーブルを参照して、 自動的に正当なチームマスター本人のデジタル 署名かどうかを判断させるリス ト正当性確認部をさらに備える請求項 8 4 に記載の情報中継装置。
8 7 . 前記情報中継装置は、
転送されてきた情報の全部または一部に添付情報を添付する付加情報添 付部をさらに備える請求項 8 4に記載の情報中継装置。
8 8 . 前記情報中継装置は、
前記暗号情報作成装置における暗号情報作成時に用いられたメ ンバ一リ ストと、 前記配信先リス トを作成するために利用したメンバ一リス トの同 一性の検証、 情報受信を拒否する受信側端末または利用者の識別情報が 含まれる受信拒否情報を取得し、 情報中継装置に転送されてきた情報の送 信者または送信側端末が、前記受信拒否情報に含まれているか否かの検証、 暗号情報の送信者がメンバ一リス 卜に含まれた者であるかかどうかの検 証、
通信経路上で暗号情報が改竄されていないか検証する完全性の検証、 転送されてきた情報の中に悪意あるプログラムやデータ列が含まれてい るかどうかの検証、 221 転送されてきた暗号情報を参照して暗号情報作成装置で作成された複数 のパーツからなる暗号情報のうち、 一部が別の情報保管装置に転送されて いるかどうかの検証、
のいずれかもしくは組合わせによる前記検証を行なう同報通信安全性検 証部をさらに備える請求項 8 4に記載の情報中継装置。
8 9 . 前記情報中継装置は、
転送されてきた情報、 または、 情報の一部を保存しておく同報通信内容 保存部をさらに備える請求項 8 4に記載の情報中継装置。
9 0 . 前記情報中継装置は、
同報通信サービスの開設受付の際に開設要求者が満たすべき開設要求項 目を開設要求者の端末に提示させる開設要求項目提示部と、
前記開設要求者が転送した開設受付要求が、前記開設要求項目を満たし、 同報通信サービスの開設を許可するか否かをを判断する開設許可判断部と、 前記開設許可判断部により同報通信サービスの開設が決定されると、 前 記開設要求者をチームマスタ一とし、 該チームマスタ一が指定したメンバ —に情報を配信する同報通信サービスを開設する同報通信開設部と、 を含む同報通信自動開設部をさらに備える請求項 8 4に記載の情報中継
9 1 . 請求項 6 9に記載のメンパーリス ト管理装置と、 請求項 7 3に 記載の暗号情報作成装置と、 請求項 7 8に記載の暗号情報複号化装置と、 請求項 8 4に記載の情報中継装置とからなる同報通信システム。
9 2 . 前記メ ンバーリス ト管理装置におけるメンバ一リ ス ト管理プロ グラムを記録した記録媒体であって、
同報通信を行う 1以上のメンバ一の公開鍵を含むメンバ一リストを作成 する手順と、
前記公開鍵を取得し保存する手順とを 222 をコンピュータに実行させるメンバーリス 卜管理プログラムを記録した コンピュータ読み取り可能な記録媒体。
9 3 . 前記暗号情報作成装置における暗号情報作成プログラムを記録し た記録媒体であって、
ネッ トワークを介して、 メンバ一リス トを取得し保存する手順と、 同報通信文を取得し、 該同報通信文を前記メンパーリストに含まれる公 開鍵を用いて暗号化し暗号化情報とする手順と
をコンピュータに実行させる暗号情報作成プログラムを記録したコンビ ュ一タ読み取り可能な記録媒体。
9 4 . 前記暗号情報復号化装置における暗号情報復号化プログラムを 記録した記録媒体であって、
前記情報中継装置から転送された暗号情報を取得する手順と、 前記暗号情報に含まれる暗号化情報を複号化する手順と
をコンピュータに実行させる暗号情報復号化プログラムを記録したコン ピュータ読み取り可能な記録媒体。
9 5 . 前記情報中継装置における情報中継プログラムを記録した記録 媒体であって、
配信先リ ストを管理する手順と、
転送されてきた暗号情報を複製する手順と、
複製された暗号情報を各被配信メンバ一に配信する手順と
をコンピュータに実行させる情報中継プログラムを記録したコンビユー タ読み取り可能な記録媒体。
9 6 . 変更指示を行う指示者の本人識別 ·認証を行うための情報を所 定の要求先に通知して、 資源を互いに共有するメンバで構成されるチーム に関わる情報と該情報の管理権限を有するマスタのデジタル署名とが含ま れ、 チームに属するメンバの権限に応じて用意されたチームデータリス ト 223 を前記要求先から取得し、 取得された該チームデータリス 卜の内容に基づ いて、 権限を持つマスタが前記チームデータリス トを作成したか否かを確 認するリス ト作成者確認部と、
該権限を持つマスタの作成であることが確認された前記チームデータリ ストに対して前記変更指示に応じた変更を加えるリス ト変更部と、 前記指示者のデジタル署名を作成し、 前記リス ト変更部で変更されたチ —ムデータリストに該デジタル署名を添付して前記要求先に送るデジタル 署名部と
を具備するチームデータリス ト管理装置。
9 7 . 前記チームデータリス トには、 前記メンバに関するメンバ情報 及び前記マスタのデジタル署名が少なく とも含まれた 1つ以上のメンバリ ス トと、 前記マスタの権限を示すマスタ情報及び前記マスタのデジタル署 名が少なく とも含まれたマスタリス トが含まれている請求項 9 6記載のチ ームデータリス ト管理装置。
9 8 . 前記マスタには前記マスタリス トの変更権限を有するチームマ スタが含まれ、 前記変更指示は前記チームマスタの変更指示であって、 前記リス ト作成者確認部は、 前記要求先に送られた前記変更されたメン パリスト及びマスタリス 卜に対応して前記要求先から返送される移行期の メンバリス ト及び移行期のマスタ リス トに含まれる前記マスタのデジタル 署名を確認し、
前記デジタル署名部は、 前記変更指示で指定された変更後のチームマス タのデジタル署名を作成し、 前記移行期のメンバリスト及び移行期のマス タリス トに該デジタル署名を付与した新メンバリスト及び新マスタリス ト を前記要求先に送り返す請求項 9 7記載のチームデータリス ト管理装置。
9 9 . 前記チームマスタの本人識別を行うための識別情報を所定の場 所から取得して登録する登録部と、 224 前記チームマスタの識別情報並びに前記要求先から送られてくる前記メ ンバリスト及び前記マスタ リス トに含まれる前記マスタのデジタル署名に 基づいて、 該マスタのデジタル署名が前記チームマスタのデジタル署名で あるか否かを確認するチームマスタ確認部とをさらに有する請求項 9 8記 載のチームデータリスト管理装置。
1 0 0 . 前記変更指示に際して取得したマスタリス ト， 前記移行期の マスタ リスト及ぴ前記新マスタリストの内容の変遷に基づいて、 前記チ一 ムマスタが正規の手続きを経て変更されたことを確認する変更確認部と、 該変更が確認されたことを条件として、 前記変更指示で指定された変更 後のチームマスタの識別情報を取得し、 該識別情報により前記登録部に登 録されている変更前のチームマスタの識別情報を更新する識別情報更新部 とをさらに有する請求項 9 9記載のチームデータリス ト管理装置。
1 0 1 . 資源を互いに共有するメンバで構成されるチームに関わる情 報と該情報の管理権限を有するマスタのデジタル署名とが含まれ、 チーム に属するメンバの権限に応じて用意されるチームデータリストを記憶する チームデータリス ト記億部と、
所定の要求元からの参照要求に対し、 前記チームデータ リ ス ト及び該要 求を行った指示者の本人識別 ·認証を行うための情報に基づいて前記指示 者が前記要求の権限を有するか否かを判断し、 権限を有する指示者の居る 要求元に対してだけ前記チームデータリストを送出する第 1 の権限確認部 と、
前記要求元からの更新要求に対し、 該要求元から送られてくるチ一ムデ —タリストの内容に基づいて該チームデータリス トの正当性を確認し、 正 当性の確認されたチームデータリス トで前記チームデータリスト記憶部の 記憶内容を更新する第 2の権限確認部と
を具備するチームデータリス ト保管装置。 225
1 0 2 . 前記チームデ一タリス 卜記憶部は、
前記メンバに関するメ ンバ情報と前記マスタのデジタル署名が少なく と も含まれた 1つ以上のメンバリス トを記憶するメンバリスト記憶部と、 前記マスタの権限を示すマスタ情報及び前記マスタのデジタル署名が少 なく とも含まれたマスタ リストを記憶するマスタ リス ト記憶部と
を有する請求項 1 0 1記載のチームデータリス ト保管装置。
1 0 3 . 前記マスタには前記マスタリス 卜の変更権限を有するチーム マスタが含まれ、 前記第 2の権限確認部は、
前記指示者から通知される前記チームマスタの変更指示に対し、 該変更 前のマスタ リ ス 卜を旧マスタリス 卜と して保持するマスタリス ト保持部と、 前記要求元からの要求で前記要求元に送出した前記マスタ リ ス ト及び前 記メンバリス トのうち、 前記チームマスタに関する情報の変更された移行 期のマスタリス ト及び移行期のメンバリストを前記要求元から受け取り、 これらリス 卜に基づいて前記チームマスタの変更を検出する部と、
該変更が検出されたことを条件として、 前記移行期のマスタ リス ト， 前 記移行期のメンバリス ト及び前記旧マスタリス トに基づいて、 前記チーム マスタの変更の正当性を確認する部と、
該正当性が確認されたことを条件として前記要求元に送出された前記移 行期のマスタ リス ト及び移行期のメ ンバリス トに対し、 前記変更指示で指 定された変更後のチームマスタのデジタル署名が添付された新マスタリス ト及び新メンバリス トを前記要求元から受け取り、 これらリス トの正当性 を確認して前記メンバリスト記憶部及び前記マスタリス ト記憶部の記憶内 容を更新する部と
をさらに有する請求項 1 0 2記載のチームデータリス ト保管装置。
1 0 4 . 要求元である請求項 9 6に記載のチームデータリスト管理装 置と、 226 要求先である請求項 1 0 1に記載のチームデータリス ト保管装置とを有 するチームデータリス ト処理システム。
1 0 5 . 変更指示を行う指示者の本人識別 ·認証を行うための情報を 所定の要求先に通知して、 資源を互いに共有するメンバで構成されるチ一 ムに関わる情報と該情報の管理権限を有するマスタのデジタル署名とが含 まれ、 チームに属するメンバの権限に応じて用意されたチームデータリス トを前記要求先から取得する処理と、
取得された該チームデータリス トの内容に基づいて、 権限を持つマスタ が前記チームデータリス トを作成したか否かを確認する確認処理と、 該確認処理によって権限を持つマスタの作成であることが確認された前 記チームデータリス トに対して前記変更指示に応じた変更を加えるリ ス ト 変更処理と、 前記指示者のデジタル署名を作成し、 前記リス ト変更処理 で変更されたチームデータリス トに該デジタル署名を添付して前記要求先 に送るデジタル署名処理と
をコンビュ一タに実行させるためのチームデータリス ト管理プログラム を記録した記録媒体。
1 0 6 . 資源を互いに共有するメンバで構成されるチームに関わる情 報と該情報の管理権限を有するマスタのデジタル署名が含まれ、 チームに 属するメンバの権限に応じて用意されるチームデータリス トを予め記憶し ておく処理と、 所定の要求元から参照要求が送られた場合に、 前記チ一 ムデータリスト及び該要求を行った指示者の本人識別 ·認証を行うための 情報に基づいて前記指示者が前記要求の権限を有するか否かを判断して、 前記指示者が前記要求の権限を有する場合にだけ前記要求元へ前記チーム デ一タ リス トを送出する処理と、
前記要求元から更新要求が送られた場合に、 該要求元から送られてくる チームデータリストの内容に基づいて該チームデータリストの正当性を確 227 認し、 該正当性が確認された場合にのみ、 記憶されている前記チームデー タ リストを更新する権限確認処理と
をコンピュータに実行させるためのチームデータリス ト保管プログラム を記録した記録媒体。
PCT/JP1999/002510 1998-05-18 1999-05-14 Systeme de partage d'informations WO1999060749A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP99919583A EP1083699A1 (en) 1998-05-18 1999-05-14 Information sharing system

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
JP10/135502 1998-05-18
JP10135502A JPH11331145A (ja) 1998-05-18 1998-05-18 情報共有システム、情報保管装置およびそれらの情報処理方法、並びに記録媒体
JP10227410A JP2000059358A (ja) 1998-08-11 1998-08-11 情報改竄検知装置および改竄検知プログラムを記録したコンピュータ読み取り可能な記録媒体
JP10/227410 1998-08-11
JP10307658A JP2000134195A (ja) 1998-10-28 1998-10-28 暗号化装置、復号化装置、方法及びその記録媒体
JP10/307658 1998-10-28
JP10/309223 1998-10-29
JP10309223A JP2000137435A (ja) 1998-10-29 1998-10-29 チームデータリスト管理装置及びチームデータリスト保管装置及びチームデータリスト処理システム、並びに、それらの記録媒体
JP10372187A JP2000196583A (ja) 1998-12-28 1998-12-28 同報通信システム
JP10/372187 1998-12-28
JP11/29384 1999-02-05
JP11029384A JP2000227879A (ja) 1999-02-05 1999-02-05 チームデータリスト管理装置及びチームデータリスト保管装置及びチームデータリスト処理システム、並びに、それらの記録媒体

Publications (2)

Publication Number Publication Date
WO1999060749A1 true WO1999060749A1 (fr) 1999-11-25
WO1999060749A8 WO1999060749A8 (fr) 2000-04-27

Family

ID=27549456

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP1999/002510 WO1999060749A1 (fr) 1998-05-18 1999-05-14 Systeme de partage d'informations

Country Status (2)

Country Link
EP (1) EP1083699A1 (ja)
WO (1) WO1999060749A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009526305A (ja) * 2006-02-10 2009-07-16 サムスン エレクトロニクス カンパニー リミテッド デバイスでｄｒｍコンテンツをローミングして使用する方法および装置
CN115174152A (zh) * 2022-06-08 2022-10-11 中国科学院信息工程研究所 一种群组测试认证加密方法、验证解密方法及通信方法
US20230094255A1 (en) * 2021-09-27 2023-03-30 7-Eleven, Inc. Autonomous delivery mechanism data integration in an application platform
CN118590326A (zh) * 2024-08-06 2024-09-03 北京清水爱派建筑设计股份有限公司 一种多平台协同建筑设计过程中数据安全共享方法及系统

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2002080447A1 (ja) * 2001-03-29 2004-07-22 ソニー株式会社 情報処理装置
US8468209B2 (en) 2003-09-18 2013-06-18 International Business Machines Corporation Method of rescinding previously transmitted e-mail messages
EP1714459B1 (en) * 2004-02-13 2016-08-03 Nokia Technologies Oy Accessing protected data on network storage from multiple devices
WO2006083141A1 (en) * 2005-02-07 2006-08-10 Samsung Electronics Co., Ltd. Key management method using hierarchical node topology, and method of registering and deregistering user using the same
KR100636228B1 (ko) 2005-02-07 2006-10-19 삼성전자주식회사 계층적인 노드 토폴로지를 이용한 키 관리 방법 및 이를이용한 사용자 등록 및 등록해제 방법
EP2104269A1 (en) 2008-03-17 2009-09-23 Robert Bosch Gmbh An electronic control unit (ECU) and a method for verifying data integrity
DE202008007826U1 (de) 2008-04-18 2008-08-28 Samedi Gmbh Anordnung zum sicheren Austausch von Daten zwischen Dienstleister und Kunde, insbesondere zur Terminplanung
US20160057466A1 (en) * 2014-08-21 2016-02-25 Real Image Media Technologies Pvt. Ltd. System and Method for Controlling Digital Cinema Content Distribution
CN107819585B (zh) * 2017-11-17 2020-08-25 武汉理工大学 Sm9数字签名协同生成方法及系统
KR102357698B1 (ko) * 2020-02-24 2022-02-14 황순영 부분 해시값을 이용한 개인키 관리 방법
US11595207B2 (en) 2020-12-23 2023-02-28 Dropbox, Inc. Utilizing encryption key exchange and rotation to share passwords via a shared folder

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07200617A (ja) * 1994-01-10 1995-08-04 Nippon Telegr & Teleph Corp <Ntt> 共有情報参照権限制御方法
JPH07245605A (ja) * 1994-03-03 1995-09-19 Fujitsu Ltd 暗号化情報中継装置とそれに接続される加入者端末装置ならびに暗号通信方法
JPH09252323A (ja) * 1996-01-11 1997-09-22 Sony Corp 通信システムおよび通信装置
JPH1013403A (ja) * 1996-06-21 1998-01-16 Nec Corp データ管理システム
JPH1040155A (ja) * 1996-07-24 1998-02-13 Fujitsu Ltd データベース管理システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07200617A (ja) * 1994-01-10 1995-08-04 Nippon Telegr & Teleph Corp <Ntt> 共有情報参照権限制御方法
JPH07245605A (ja) * 1994-03-03 1995-09-19 Fujitsu Ltd 暗号化情報中継装置とそれに接続される加入者端末装置ならびに暗号通信方法
JPH09252323A (ja) * 1996-01-11 1997-09-22 Sony Corp 通信システムおよび通信装置
JPH1013403A (ja) * 1996-06-21 1998-01-16 Nec Corp データ管理システム
JPH1040155A (ja) * 1996-07-24 1998-02-13 Fujitsu Ltd データベース管理システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
APPLIED CRYPTOGRAPHY SECOND EDITION, "3.1 Key Exchange" (U.S.), John Wiley & Sons, Inc., (1996), pages 47-52. *
MASAHIRO MITSUYASU, EIJI OKAMOTO: "Kagi haisou, kagi kanri to ninshou", BIT, vol. 28, no. 8, August 1996 (1996-08-01), pages 87 - 95 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009526305A (ja) * 2006-02-10 2009-07-16 サムスン エレクトロニクス カンパニー リミテッド デバイスでｄｒｍコンテンツをローミングして使用する方法および装置
US9300668B2 (en) 2006-02-10 2016-03-29 Samsung Electronics Co., Ltd. Method and apparatus for roaming digital rights management content in device
US20230094255A1 (en) * 2021-09-27 2023-03-30 7-Eleven, Inc. Autonomous delivery mechanism data integration in an application platform
US12062004B2 (en) * 2021-09-27 2024-08-13 7-Eleven, Inc. Autonomous delivery mechanism data integration in an application platform
CN115174152A (zh) * 2022-06-08 2022-10-11 中国科学院信息工程研究所 一种群组测试认证加密方法、验证解密方法及通信方法
CN118590326A (zh) * 2024-08-06 2024-09-03 北京清水爱派建筑设计股份有限公司 一种多平台协同建筑设计过程中数据安全共享方法及系统

Also Published As

Publication number Publication date
EP1083699A1 (en) 2001-03-14
WO1999060749A8 (fr) 2000-04-27

Similar Documents

Publication Publication Date Title
US11038670B2 (en) System and method for blockchain-based cross-entity authentication
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
EP3814948B1 (en) System and method for blockchain-based cross-entity authentication
EP3788523B1 (en) System and method for blockchain-based cross-entity authentication
US6092201A (en) Method and apparatus for extending secure communication operations via a shared list
US7644268B2 (en) Automated electronic messaging encryption system
US5774552A (en) Method and apparatus for retrieving X.509 certificates from an X.500 directory
KR100734737B1 (ko) 조건부 전자 서명의 생성 방법, 조건부 전자 서명의 검증 방법, 데이터 처리 장치 및 컴퓨터 판독 가능 기록 매체
AU2002230823B2 (en) Method and system for obtaining digital signatures
US6792531B2 (en) Method and system for revocation of certificates used to certify public key users
US6438690B1 (en) Vault controller based registration application serving web based registration authorities and end users for conducting electronic commerce in secure end-to-end distributed information system
US20020032857A1 (en) Person identification certificate link system, information processing apparatus, information processing method, and program providing medium
US6215872B1 (en) Method for creating communities of trust in a secure communication system
CN103124981A (zh) 电子文档分发系统和电子文档分发方法
JP4040886B2 (ja) コンテンツ管理システムおよびコンテンツ管理方法
WO1999060749A1 (fr) Systeme de partage d&#39;informations
KR102015386B1 (ko) 전자 메일 배달의 인증을 위한 방법
JP2000196583A (ja) 同報通信システム
US6795920B1 (en) Vault controller secure depositor for managing secure communication
US7716478B2 (en) Method and device for data protection
López et al. Hierarchical organization of certification authorities for secure environments
KR20240039076A (ko) 디지털인감증명과 블록체인 기반의 내용증명 방법
Bai et al. Access revocation and prevention of false repudiation in secure email exchanges
Lipp et al. The digital signature initiative
Hutchison Security in group applications: Lotus Notes as case study

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WR Later publication of a revised version of an international search report
WWE Wipo information: entry into national phase

Ref document number: 1999919583

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1999919583

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09700390

Country of ref document: US

WWW Wipo information: withdrawn in national office

Ref document number: 1999919583

Country of ref document: EP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载