WO2022259494A1 - 通信システム、ユーザ端末、通信方法および通信プログラム - Google Patents

通信システム、ユーザ端末、通信方法および通信プログラム Download PDF

Info

Publication number
WO2022259494A1
WO2022259494A1 PCT/JP2021/022218 JP2021022218W WO2022259494A1 WO 2022259494 A1 WO2022259494 A1 WO 2022259494A1 JP 2021022218 W JP2021022218 W JP 2021022218W WO 2022259494 A1 WO2022259494 A1 WO 2022259494A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
user terminal
file
file attached
server device
Prior art date
Application number
PCT/JP2021/022218
Other languages
English (en)
French (fr)
Inventor
宏樹 伊藤
真一 平田
英雄 森
武生 長島
Original Assignee
日本電信電話株式会社
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
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/022218 priority Critical patent/WO2022259494A1/ja
Priority to JP2023526784A priority patent/JPWO2022259494A1/ja
Priority to US18/567,784 priority patent/US20240146513A1/en
Publication of WO2022259494A1 publication Critical patent/WO2022259494A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • 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

Definitions

  • the present invention relates to a communication system, user terminal, communication method and communication program.
  • the mail server at location A The mail text (including attached files, etc.) is encrypted using the corresponding public key, and sent to the destination domain (site B). Also, the mail server at site B confirms whether or not the received mail is encrypted, and if it is encrypted, it decrypts it using the private key stored in the mail server and delivers it to the user terminal.
  • public key cryptography is generally used to encrypt and decrypt messages or attached files between message senders and receivers and to keep communications confidential during the route.
  • Common public-key cryptography implementations involve sharing a key pair, i.e., the public key required to create an encrypted message or attachment that can only be decrypted by the message recipient. must be obtained in advance of attachment encryption.
  • IBE Identity Based Encryption
  • ID-based cryptography is one of the methods of public key cryptography, and is characterized by a method of generating a private key after defining a public key when generating a key pair of a private key and a public key. Therefore, it is possible to use an identifier such as a mail address, a name, or an arbitrary character string designated by a person who performs decryption as a public key.
  • the sender encrypts a message or email attachment using the identifier obtained from the key generator, in the same way as ciphertext generation and decryption using ordinary public key cryptography, Send to recipient.
  • the recipient decrypts the encrypted message or email attachment using the private key obtained from the key generator.
  • Attribute Based Encryption ABE as a method for performing encryption and decryption using attributes related to the recipient (name of department, position, deadline for decryption, etc.) as conditions for decryption.
  • Attribute-based encryption encrypts a message or email attachment file to be decrypted, including the decryption condition policy, and sends it to the recipient. This is a method that enables decryption of the encrypted message or mail attachment file only when the recipient conforms to the policy.
  • policies include identifiers of decryptable users, identifiers of decryptable organizations (groups of users), times when decryption is allowed, and so on.
  • the private key held by the recipient includes the user's identifier, the organization's identifier, and the like.
  • the sender creates a ciphertext in which the policy information that combines these conditions is embedded in the message or email attachment to be decrypted. Decryption is performed when it is suitable for the policy such as the identifier and the timing of decryption.
  • attribute-based encryption is generally implemented including ID-based encryption, these two techniques will be collectively referred to as "attribute-based encryption”.
  • there is a cloud key management technology as a method of managing the private key in the public key cryptosystem not on the terminal on the decryption side but on the network side.
  • Key escrow technology is generally known as a method for managing private keys on a network that should be managed on user terminals and devices such as IC cards owned by users. Key escrow technology allows keys (common keys, private keys) that should be kept secret in cryptographic communication to be transferred to third parties other than the sender and receiver of the ciphertext (for example, administrators of networks and applications, and administrators of organizations). The ciphertext between the sender and receiver can be decrypted by these administrators as needed.
  • cloud key management technology entrusts the key that should be kept confidential in encrypted communication to a third party other than the sender and receiver of the ciphertext, and allows the third party to decrypt the ciphertext. is the same as key escrow technology.
  • a receiver who wants to decrypt an encrypted communication performs a disturbance process when providing the ciphertext to a third party.
  • the disturbance-processed ciphertext is decrypted by a third party while the disturbance process is completed, and is provided to the recipient.
  • a third party cannot view the plaintext that has been deencrypted and disturbed at the time of decryption.
  • the recipient can keep the communication confidential from not only the person who defrauded the communication on the communication path, but also the third party who performs the decryption process.
  • the confidentiality of communication between the mail server at site A and the mail server at site B is guaranteed based on the encryption method of the email text (including attached files, etc.).
  • the text of the mail (including the attached file, etc.) decrypted into plain text by the mail server of each base is distributed as plain text within the base.
  • the encryption function and decryption function are executed on the user terminal that sends and receives the e-mail. is also widely practiced.
  • the mail text (including attached files and the like) is encrypted and decrypted for each mail server.
  • E-mails and attached files decrypted on the mail server are distributed in plain text on the closed network within the same site. If there is an attack to intrude into the closed network, the content of decrypted e-mails and attached files may be easily viewed by attackers.
  • the recipient of an email sent by the sender to the wrong address can check the contents. Confidentiality of the e-mail text and attached files downloaded to the user's terminal is guaranteed based on the position, work content, department, work project, etc., and is not related to the work that requires the document. , it is necessary to make it impossible for other employees to easily refer to the text of the email (including attached files, etc.).
  • the communication system of the present invention is a communication system having a user terminal for transmitting and receiving messages, and a server device for managing public and private keys. , when the user terminal transmits the message to another user terminal, the user terminal obtains a public key corresponding to the identification information of the recipient of the message, and uses the obtained public key to transmit the message or the message.
  • An encryption unit that encrypts an attached file, a transmission unit that transmits the message in which the message or the file attached to the message is encrypted by the encryption unit to another user terminal, and another user terminal a request unit for requesting the server device to decrypt the message or a file attached to the message when the message is received from the server device, and receiving the decrypted message or the file from the server device; , wherein the server device includes a key issuing unit that issues a private key corresponding to identification information of a recipient of the message, and a request for decryption of the message or a file attached to the message to the user terminal.
  • the key issuing unit when the private key issued by the key issuing unit is used to decrypt the message or the file attached to the message, and the decrypted message or the file is sent to the decryption and a decoding unit for transmitting to a user terminal that has made a request.
  • FIG. 1 is a block diagram showing a configuration example of a communication system according to the first embodiment.
  • FIG. 2 is a sequence diagram illustrating an example of the processing flow of the communication system according to the first embodiment;
  • FIG. 3 is a sequence diagram illustrating an example of the processing flow of the communication system according to the first embodiment;
  • FIG. 4 is a sequence diagram illustrating an example of the processing flow of the communication system according to the first embodiment;
  • FIG. 5 is a block diagram showing a configuration example of a communication system according to the second embodiment.
  • FIG. 6 is a sequence diagram showing an example of the processing flow of the communication system according to the second embodiment.
  • FIG. 7 is a sequence diagram illustrating an example of the processing flow of the communication system according to the second embodiment.
  • FIG. 8 is a sequence diagram illustrating an example of the processing flow of the communication system according to the second embodiment.
  • FIG. 9 is a diagram showing an example of an encryption policy setting screen.
  • FIG. 10 is a diagram showing a computer that executes a
  • Embodiments of the communication system, user terminal, communication method, and communication program according to the present application will be described in detail below with reference to the drawings. Note that the communication system, user terminal, communication method, and communication program according to the present application are not limited by this embodiment.
  • FIG. 1 is a block diagram showing a configuration example of a communication system according to the first embodiment. Note that the configuration shown in FIG. 1 is merely an example, and the specific configuration is not particularly limited.
  • the communication system of this embodiment comprises a message server 101 and a user environment 161 on the network 1, which are interconnected within the network 1. Also provided on the network 2 is a message server 102 and a user environment 162 which are interconnected within the network 2 .
  • the user environments 161 and 162 may have any configuration, but include at least user terminals.
  • a cloud key management server 171 is provided on the network 4.
  • Network 1, network 2, and network 4 are interconnected.
  • the message server 101 and the message server 102 have the same configuration because they mutually exchange messages using the same protocol.
  • the user environment 161 and the user environment 162 are assigned to individual users and exchange messages with each other, so they have the same configuration.
  • network 1 and network 2 have the same configuration.
  • a message is sent from the user environment 161 to the user environment 162 as an example.
  • the message server 101 includes a message receiving unit 101a that receives messages sent from the message transmission/reception function of the user environment 161, a message DB 101b that temporarily stores messages, and a user environment 141 that is used by the user to whom the message is addressed. a message sending unit 101c that identifies a message addressed to the user based on a message reception request from the user and sends the message to the user environment 141; Note that the message server 102 has the same configuration as that of the message server 101, so a description thereof will be omitted.
  • the user environment 161 includes a message transmission/reception unit 161a that distributes messages via the message server 101 and the message server 102; includes a perturbation unit 161c that perturbs the attached file of the message.
  • the user environment 162 has the same configuration as the user environment 161, so description thereof will be omitted.
  • the encryption unit 161b When transmitting a message to another user terminal (user environment 162), the encryption unit 161b acquires a public key corresponding to the identification information of the recipient of the message (e.g., the email address of the recipient). Encrypt a message or a file attached to a message with a public key. For example, the encryption unit 161b uses existing ID-based encryption to encrypt a message or a file attached to the message using an identifier such as the recipient's email address or name as a public key (see reference 1, for example). .
  • Reference 1 Kobayashi, Yamamoto, Suzuki, Hirata, "Application of ID-based cryptography and keyword search cryptography", NTT Technical Journal, February 2010
  • the message transmission/reception unit 161a has a transmission unit 1610 and a request unit 1611.
  • the transmission unit 1610 transmits the message encrypted by the encryption unit 161b or the file attached to the message to another user terminal (user environment 162).
  • the request unit 1611 When the request unit 1611 receives a message from another user terminal (user environment 162), it requests the cloud key management server 171 to decrypt the message or a file attached to the message. Receive decrypted messages or files.
  • the disturbing unit 161c disturbs the message encrypted by the encrypting unit 161b or the file attached to the message.
  • the cloud key management server 171 has a key issuing unit 171a, a key management unit 171b, and a decryption unit 171c.
  • the key issuing unit 171a issues a private key corresponding to the identification information of the recipient of the message.
  • the key management unit 171b stores public keys and private keys corresponding to message recipients. For example, when the key management unit 171b receives a request for a secret key from the user environment 161, and stores the requested secret key, it transmits the secret key to the user environment 161 and stores the requested secret. If the key is not stored, it requests the key issuing unit 171 a to issue a private key, and then transmits the issued private key to the user environment 161 .
  • the decryption unit 171c When the decryption unit 171c receives a request for decrypting a message or a file attached to the message from the user terminal (user environment 161), the decryption unit 171c uses the private key issued by the key issuing unit 171a to decrypt the message or The file attached to the message is decrypted, and the decrypted message or file is sent to the user terminal (user environment 161) that made the decryption request.
  • FIG. 2 to 4 are sequence diagrams showing an example of the processing flow of the communication system according to the first embodiment.
  • the message sender uses the user environment 161 to compose a message addressed to the recipient of the message.
  • the body of the message or attachments to the message are intended to prevent viewing by third parties other than the sender of the message or the recipient of the message.
  • the message sender designates a message or an attached file of the message, and an identifier of the message recipient (for example, recipient's mail address) (S000).
  • the message transmission/reception unit 161a of the user environment 161 requests the encryption unit 161b to encrypt the message or the attached file using the identifier of the message recipient as the public key (S001).
  • the encryption unit 161b uses the public key to encrypt the message or attached file (S002), and responds to the message transmission/reception unit 161a (S003).
  • the message transmission/reception unit 161a of the user environment 161 transmits the encrypted message or the encrypted attached file to the message server 101 (S004).
  • the message server 101 transmits the encrypted message or the encrypted attached file to the message server 102 of the network 2 to which the user environment 161 used by the message recipient belongs (S005).
  • the message transmission/reception unit 162a of the user environment 162 requests the message server 102 to acquire a new message (S021). Then, the message server 102 searches for a new message addressed to the message recipient (S022), and sends the new message to the message transmission/reception unit 162a of the user environment 162 (S023).
  • the message transmission/reception unit 162a of the user environment 162 confirms whether or not the new message has an encrypted message or an encrypted attached file (S024). If the encrypted attached file is included, the disturbance unit 162c is requested to process the encrypted message or the encrypted attached file (S025). The disturbance unit 162c performs disturbance processing (S026), and responds to the message transmission/reception unit 162a with the disturbed encrypted message or the disturbed encrypted attached file (S027).
  • the message transmission/reception unit 162a of the user environment 162 transmits the disturbed encrypted message or the disturbed encrypted attached file to the encryption processing function on the cloud key management server 171, and requests decryption (S028 ).
  • the decryption unit 171c then requests the private key corresponding to the message recipient from the key management unit 171b on the cloud key management server 171 (S029).
  • the key management unit 171b requests the key issuing function on the cloud key management server 171 to issue a private key (S031).
  • the key issuing unit 171a issues a private key corresponding to the message recipient (S032) and responds to the key managing unit 171b (S033).
  • the key management unit 171b responds with the secret key to the encryption processing function (S034).
  • the decrypting unit 171c decrypts the disturbed encrypted message or the disturbed encrypted attached file using the secret key (S035), and decrypts the disturbed encrypted mail or the disturbed decrypted attached file. It responds to the message transmitter/receiver 162a on the user environment 162 (S036).
  • the message transmission/reception unit 162a of the user environment 162 requests the disturbance release of the disturbed message or the disturbed attached file to the disturber 162c (S037).
  • the disturbance unit 162c performs disturbance cancellation processing (S038), and responds with the disturbed encrypted message or the disturbed encrypted attached file to the message transmitter/receiver 162a (S039).
  • the communication system when sending an email, the public key corresponding to the identification information of the message recipient is obtained and encrypted, and when receiving the email, the cloud key management server 171 is requested to decrypt it, so that the key can be managed by the user terminal. It is possible to send and receive messages more easily and safely without using For example, in the communication system according to the first embodiment, between the sender's user environment 161 and the recipient's user environment 162, using a public key corresponding to the identification information of the recipient of the message, can encrypt attachments and send and receive them. Also, in the communication system according to the first embodiment, it is possible to realize a secure message transmission/reception function in which key management on the user terminal side is minimized.
  • FIG. 5 is a block diagram showing a configuration example of a communication system according to the second embodiment. As shown in FIG. 5, networks 1 and 2 have directory servers 111 and 112, respectively.
  • the directory server 111 manages attributes related to users existing on the network 1 and provides the attributes in response to requests for other functions. Attributes here include an identifier that identifies the user, such as an email address or an account name at the time of login, affiliation information indicating the group to which the user belongs, position, authority, etc., and other information within the network. It includes general attribute information associated with an individual, such as name, which is necessary for the user to use not only this system but also systems connected to the network.
  • the directory server 111 has an attribute management unit 111a.
  • the attribute management unit 111a stores attribute information of each user, identifiers necessary for exchanging messages managed within the network, and user accounts used within the network.
  • the attribute management unit 111a stores, as attribute information, affiliation information indicating the group to which each user belongs, position, authority, and the like. Note that the directory server 111 and the directory server 112 have the same configuration, and the description of the directory server 112 is omitted.
  • the encryption unit 161b of the user environment 161 acquires a public key corresponding to the attribute information of the recipient of the message, and uses the acquired public key as to encrypt messages or files attached to messages.
  • the encryption unit 161b may encrypt a message or a file attached to the message including policy information indicating conditions for enabling decryption.
  • the encryption unit 161b may use an existing attribute-based encryption method to encrypt a decryption target message or email attachment including a policy of decryption conditions (for example, see Reference 2).
  • Reference 2 Abe, Tokunaga, Mehdi, Nishimaki, Kusakawa, "Forefront of Cryptographic Theory Research Corresponding to Changes in Computing Environment", NTT Technical Journal, February 2020
  • policies include identifiers of decryptable users, identifiers of decryptable organizations (groups of users), times when decryption is allowed, and so on.
  • the encryption unit 161b adds policy information that combines conditions such as a decryptable user identifier, a decryptable organization (group of users) identifier, and decryptable time to a message or email attachment to be decrypted. Generate embedded ciphertext.
  • the key issuing unit 171a links the user account, the organization to which the user account belongs, affiliation information such as position, available time zone, available terminal or available network, etc., to the message Generates a key pair that enables encryption and decryption of the text or attached file.
  • the decryption unit 171c of the cloud key management server performs decryption when the identification information embedded in the recipient's private key, the timing of decryption, etc. are suitable for the policy.
  • the private key held by the recipient includes, for example, the identifier of the user, the identifier of the organization, and the like.
  • FIG. 6 to 8 are sequence diagrams showing an example of the processing flow of the communication system according to the second embodiment.
  • the message transmitter/receiver 161a of the user environment 161 sends the identifier of the message receiver to the directory server 111 when the message sender creates a message addressed to the message receiver. Based on this, request is made for affiliation information indicating the group to which the message receiver belongs, position, authority, etc. (S101).
  • the directory server 111 acquires affiliation information related to the message recipient from the attribute management function based on the identifier of the message recipient (S102), and provides the affiliation information to the message transmission/reception unit 161a of the user environment 161 ( S103).
  • FIG. 9 is a diagram showing an example of an encryption policy setting screen.
  • the message transmission/reception unit 161a of the user environment 161 requests the encryption processing function to encrypt the message or attached file based on the encryption policy (S105). Then, the encryption unit 161b encrypts the message or attached file using the identifier and the encryption policy (S106). Since the flow of subsequent processing is the same as that of the first embodiment, description thereof is omitted.
  • each component of each device illustrated is functionally conceptual, and does not necessarily need to be physically configured as illustrated.
  • the specific form of distribution/integration of each device is not limited to the illustrated one, and all or part of them can be functionally or physically distributed/integrated in arbitrary units according to various loads and usage conditions. Can be integrated and configured.
  • the operation log acquisition device may detect an event of an operation screen displayed on another terminal and record the operation log.
  • each processing function performed by each device may be implemented in whole or in part by a CPU and a program analyzed and executed by the CPU, or implemented as hardware based on wired logic.
  • FIG. 10 is a diagram showing a computer that executes a communication program.
  • the computer 1000 has a memory 1010 and a CPU 1020, for example.
  • Computer 1000 also has hard disk drive interface 1030 , disk drive interface 1040 , serial port interface 1050 , video adapter 1060 and network interface 1070 . These units are connected by a bus 1080 .
  • the memory 1010 includes a ROM 1011 and a RAM 1012.
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • Hard disk drive interface 1030 is connected to hard disk drive 1031 .
  • Disk drive interface 1040 is connected to disk drive 1041 .
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041 .
  • the serial port interface 1050 is connected to a mouse 1051 and a keyboard 1052, for example.
  • Video adapter 1060 is connected to display 1061, for example.
  • the hard disk drive 1031 stores an OS (Operating System) 1091, application programs 1092, program modules 1093, and program data 1094, for example. That is, a program that defines each process of each device is implemented as a program module 1093 in which code executable by the computer 1000 is described.
  • Program modules 1093 are stored, for example, in hard disk drive 1031 .
  • the hard disk drive 1031 stores a program module 1093 for executing processing similar to the functional configuration in the user terminal.
  • the hard disk drive 1031 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the embodiment described above is stored as the program data 1094 in the memory 1010 or the hard disk drive 1031, for example. Then, the CPU 1020 reads out the program modules 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1031 to the RAM 1012 as necessary and executes them.
  • the program modules 1093 and program data 1094 are not limited to being stored in the hard disk drive 1031, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program modules 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Program modules 1093 and program data 1094 may then be read by CPU 1020 through network interface 1070 from other computers.
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

ユーザ環境（１６１）が、他のユーザ環境（１６２）にメッセージを送信する場合に、メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、メッセージまたはメッセージに添付されるファイルを暗号化する。そして、ユーザ環境（１６１）が、メッセージまたはメッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する。また、ユーザ環境（１６２）が、他のユーザ環境（１６１）からメッセージを受信した場合には、メッセージまたはメッセージに添付されるファイルの復号化をクラウド鍵管理サーバ（１７１）に要求し、クラウド鍵管理サーバ（１７１）から復号化されたメッセージまたはファイルを受信する。

Description

通信システム、ユーザ端末、通信方法および通信プログラム
　本発明は、通信システム、ユーザ端末、通信方法および通信プログラムに関する。
　従来、メッセージ送受信の一形態として電子メールを用いる場合において、インターネットを経由して２拠点間にセキュアにメール送受信を行うための技術が知られている（例えば、特許文献１参照）。
　このような技術では、例えば、拠点Ａにおけるメールサーバは、ユーザ端末から送信されたメールの宛先アドレスの中の宛先ドメイン（拠点Ｂ）が特定の暗号化対象のドメインである場合、当該宛先ドメインに対応した公開鍵を用いてメール本文（添付ファイル等を含む）を暗号化し、宛先ドメイン（拠点Ｂ）に送付する。また、拠点Ｂにおけるメールサーバは、受信したメールの暗号化有無を確認し、暗号化されている場合は、メールサーバに格納されている秘密鍵を用いて復号し、ユーザ端末に配信する。
　また、メッセージ送受信者間でメッセージ乃至は添付ファイル等の暗号化、復号を行い、途中経路での通信を秘匿する為に、公開鍵暗号方式が一般的に用いられている。一般的な公開鍵暗号方式の実施のためには、鍵ペアの共有、即ちメッセージ受信者のみが復号可能な暗号化メッセージ乃至は添付ファイルの作成に必要な公開鍵を、メッセージ送信者はメッセージ乃至は添付ファイルの暗号化の事前に入手する必要がある。
　これに対し、既知の識別子を公開鍵として利用し、暗号化、復号に必要な秘密鍵を生成する方式として、ＩＤベース暗号（Identity　Based　Encryption,　IBE）が存在する。ＩＤベース暗号は公開鍵暗号技術の方式の１つであり、秘密鍵、公開鍵の鍵ペア生成に際して、公開鍵を定義した後に秘密鍵を生成する方式であることを特徴とする。このため、メールアドレス、氏名、あるいは復号を行う者が指定した任意の文字列、等の識別子（Identifier）を公開鍵として用いることが可能である。
　ＩＤベース暗号では、通常の公開鍵暗号を用いた暗号文の生成、復号と同様に、送信者は、鍵生成者から取得した、前記識別子を用いてメッセージ乃至はメールの添付ファイルを暗号化し、受信者に送信する。受信者は、鍵生成者から取得した秘密鍵を用いて、前記暗号化されたメッセージ乃至はメールの添付ファイルを復号する。
　また、受信者に関する属性（所属する部課名、役職、復号可能な期限、等）を復号可能な条件として暗号化、復号を行う方式として、属性ベース暗号（Attribute　Based　Encryption,　ABE）が存在する。
　属性ベース暗号は、復号対象のメッセージ乃至はメールの添付ファイルに、復号条件のポリシを含め暗号化し、受信者に送信する。受信者がポリシに適した場合のみ、前記暗号化されたメッセージ乃至はメールの添付ファイルを復号可能とする方式である。
　ポリシの例としては、復号可能なユーザの識別子、復号可能な組織（ユーザの集合）の識別子、復号可能な時間、等がある。また、受信者が持つ秘密鍵には、ユーザの識別子、組織の識別子、等が含まれる。送信者は、復号対象のメッセージ乃至はメールの添付ファイルに、これらの条件を組み合わせたポリシ情報を埋め込んだ暗号文を生成し、受信者が復号する際には、受信者が持つ秘密鍵に埋め込まれた識別子や、復号のタイミング等のポリシに適した場合に、復号化を行う。以下、本明細書においては、一般的に属性ベース暗号は、ＩＤベース暗号を包含する実装がなされていることから、これら２つの技術の総称として「属性ベース暗号」と記載する。更に、公開鍵暗号方式における秘密鍵を復号側の端末ではなくネットワーク側で管理する方式として、クラウド鍵管理技術が存在する。
　一般に、ユーザ端末や、ユーザが所持するＩＣカード等のデバイス上で管理されるべき秘密鍵をネットワーク上で管理する方式として、キーエスクロー（鍵預託）技術が知られている。キーエスクロー技術は、暗号通信で秘匿にされるべき鍵（共通鍵、秘密鍵）を、暗号文の送信者、受信者以外の第三者（例えば、ネットワークやアプリケーションの管理者や、組織の管理者）に管理させておき、必要に応じてこれら管理者が送信者、受信者間の暗号文を復号可能とする。
　これに対して、クラウド鍵管理技術は、暗号通信で秘匿にされるべき鍵を、暗号文の送信者、受信者以外の第三者に預託し、第三者にて暗号文を復号させることはキーエスクロー技術と同一である。ただし、クラウド鍵管理技術においては、暗号化された通信文（暗号文）を復号させたい受信者は、暗号文を第三者に提供するに際して、撹乱処理を行う。撹乱処理済暗号文は撹乱処理済のまま第三者にて復号され、受信者に提供される。このとき、第三者は復号時に暗号化および撹乱を解除した平文を閲覧することができない。受信者は、通信文を通信経路上にて通信文を詐取した者のみならず、復号処理を行う第三者を含めた、受信者以外に秘匿にできる。
特開２０１１－２１７２６８号公報
　しかしながら、従来の技術では、ユーザ端末で鍵管理することなく、より簡単かつ安全なメッセージ送受信ができない場合があった。
　例えば、従来技術では、拠点Ａのメールサーバと、拠点Ｂのメールサーバとの間の通信にかかる機密性は、メール本文（添付ファイル等を含む）の暗号化方式に基づいて担保される。しかしながら、各拠点のメールサーバにて平文に復号されたメール本文（添付ファイル等を含む）は、拠点内部で平文のまま流通する。また、メール送信者と、メール受信者との間で、送受信されるメール、添付ファイル等を暗号化、復号する為に、メールを送受信するユーザ端末上で、暗号化機能、復号機能を実行することも広く実施されている。
　これらの従来技術においては、下記のような課題が考えられる。まず、一目の課題として、例えば、メールサーバ単位でメール本文（添付ファイル等を含む）が暗号化、復号される。メールサーバ上で復号されたメール、添付ファイルは、同一拠点内の閉域ネットワーク上では平文で流通する。閉域ネットワーク内部に侵入する攻撃があった場合、復号されたメール、添付ファイルは容易にその内容を攻撃者に閲覧される可能性がある。
　また、二つ目の課題として、例えば、送信者が宛先を誤って送付したメール（同一ドメインの異なる宛先のユーザに宛てた誤送信メール）の受信者は、その内容を確認可能である。ユーザ端末上にダウンロードされたメール本文や添付ファイルは、役職、業務内容、所属部署、所属する業務プロジェクト、等に基づいて、文書の機密性は担保され、当該文書を必要とする業務に関係ない、他の社員が容易にメール本文（添付ファイル等を含む）を参照不可能とする必要がある。
　また、三つ目の課題として、例えば、メール送信者と、メール受信者との間で、送受信されるメール、添付ファイル等を暗号化、復号する場合において、メール送信者と、メール受信者との間で、暗号化、復号化に必要な鍵（共通鍵、乃至は公開鍵および秘密鍵）を必要とするが、ユーザ端末上での鍵管理は煩雑である。
　本発明は、上記に鑑みてなされたものであって、ユーザ端末で鍵管理することなく、より簡単かつ安全なメッセージ送受信ができる通信システム、ユーザ端末、通信方法および通信プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明の通信システムは、メッセージの送信および受信を行うユーザ端末と、公開鍵と秘密鍵を管理するサーバ装置とを有する通信システムであって、前記ユーザ端末は、他のユーザ端末に前記メッセージを送信する場合に、前記メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルを暗号化する暗号化部と、前記暗号化部によって前記メッセージまたは前記メッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する送信部と、他のユーザ端末から前記メッセージを受信した場合には、前記メッセージまたは前記メッセージに添付されるファイルの復号化を前記サーバ装置に要求し、前記サーバ装置から復号化された前記メッセージまたは前記ファイルを受信する要求部と、を有し、前記サーバ装置は、前記メッセージの受信者の識別情報に対応する秘密鍵を発行する鍵発行部と、前記メッセージまたは前記メッセージに添付されるファイルの復号化の要求を前記ユーザ端末から受け付けた場合には、前記鍵発行部によって発行された秘密鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルの復号化を行い、復号化した前記メッセージまたは前記ファイルを前記復号化の要求を行ったユーザ端末に送信する復号化部とを有することを特徴とする。
　本発明によれば、ユーザ端末で鍵管理することなく、より簡単かつ安全なメッセージ送受信を行うことが可能となる。
図１は、第１の実施形態に係る通信システムの構成例を示すブロック図である。 図２は、第１の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。 図３は、第１の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。 図４は、第１の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。 図５は、第２の実施形態に係る通信システムの構成例を示すブロック図である。 図６は、第２の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。 図７は、第２の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。 図８は、第２の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。 図９は、暗号化ポリシの設定画面の一例を示す図である。 図１０は、通信プログラムを実行するコンピュータを示す図である。
　以下に、本願に係る通信システム、ユーザ端末、通信方法および通信プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係る通信システム、ユーザ端末、通信方法および通信プログラムが限定されるものではない。
［第１の実施形態］
　以下の実施の形態では、第１の実施形態に係る通信システムの構成、通信システムの処理の流れを順に説明し、最後に第１の実施形態による効果を説明する。
［通信システムの構成］
　まず、図１を用いて、本実施形態の通信システムの構成例を説明する。図１は、第１の実施形態に係る通信システムの構成例を示すブロック図である。なお、図１に示す構成は一例にすぎず、具体的な構成は特に限定されない。
　図１に示すように、本実施形態の通信システムは、ネットワーク１上に、メッセージサーバ１０１と、ユーザ環境１６１と、を備え、これらはネットワーク１内部で相互に接続する。また、ネットワーク２上に、メッセージサーバ１０２と、ユーザ環境１６２と、を備え、これらはネットワーク２内部で相互に接続する。なお、ここで、ユーザ環境１６１、１６２とは、どのような構成であってもよいが、少なくともユーザ端末を含むものである。
　また、ネットワーク４上に、クラウド鍵管理サーバ１７１を備える。また、ネットワーク１と、ネットワーク２と、ネットワーク４、とは、相互に接続する。なお、メッセージサーバ１０１と、メッセージサーバ１０２と、は同一プロトコルのメッセージ送受信を相互に行う関係であることから、同一構成である。
　また、ユーザ環境１６１と、ユーザ環境１６２と、は、個々のユーザに割り当てられ、お互いにメッセージの送受信を行うことから、同一構成である。然るに、ネットワーク１と、ネットワーク２と、は同一構成である。ただし、以下の説明では、主に、ユーザ環境１６１からユーザ環境１６２に対し、メッセージを送信する場合の例を前提として説明を行う。
　メッセージサーバ１０１は、ユーザ環境１６１のメッセージ送受信機能から送信されたメッセージを受信する、メッセージ受信部１０１ａと、メッセージを一時的に蓄積するメッセージＤＢ１０１ｂと、メッセージの宛先のユーザが利用する、ユーザ環境１４１からのメッセージ受信要求に基づき、ユーザに宛てたメッセージを特定し、ユーザ環境１４１に対してメッセージを送信する、メッセージ送信部１０１ｃと、を備える。なお、メッセージサーバ１０２は、メッセージサーバ１０１と同様の構成であるため、説明を省略する。
　ユーザ環境１６１は、メッセージサーバ１０１と、メッセージサーバ１０２と、を介してメッセージを流通する、メッセージ送受信部１６１ａと、メッセージ乃至はメッセージの添付ファイルの暗号化に必要な暗号化部１６１ｂと、メッセージ乃至はメッセージの添付ファイルを攪乱する攪乱部１６１ｃと、を備える。なお、ユーザ環境１６２は、ユーザ環境１６１と同様の構成であるため、説明を省略する。
　暗号化部１６１ｂは、他のユーザ端末（ユーザ環境１６２）にメッセージを送信する場合に、メッセージの受信者の識別情報（例えば、受信者のメールアドレス）に対応する公開鍵を取得し、取得した公開鍵を用いて、メッセージまたはメッセージに添付されるファイルを暗号化する。例えば、暗号化部１６１ｂは、既存のＩＤベース暗号を用いて、受信者のメールアドレスや氏名等の識別子を公開鍵としてメッセージまたはメッセージに添付されるファイルを暗号化する（例えば参考文献１参照）。
参考文献１：小林、山本、鈴木、平田、「IDベース暗号の応用とキーワード検索暗号」、NTT技術ジャーナル、2010年2月
　メッセージ送受信部１６１ａは、送信部１６１０および要求部１６１１を有する。送信部１６１０は、暗号化部１６１ｂによって暗号化されたメッセージまたはメッセージに添付されるファイルを他のユーザ端末（ユーザ環境１６２）に送信する。
　要求部１６１１は、他のユーザ端末（ユーザ環境１６２）からメッセージを受信した場合には、メッセージまたはメッセージに添付されるファイルの復号化をクラウド鍵管理サーバ１７１に要求し、クラウド鍵管理サーバ１７１から復号化されたメッセージまたはファイルを受信する。
　攪乱部１６１ｃは、暗号化部１６１ｂによって暗号化されたメッセージまたはメッセージに添付されるファイルを攪乱する。
　クラウド鍵管理サーバ１７１は、鍵発行部１７１ａ、鍵管理部１７１ｂおよび復号化部１７１ｃを有する。鍵発行部１７１ａは、メッセージの受信者の識別情報に対応する秘密鍵を発行する。
　鍵管理部１７１ｂは、メッセージ受信者に対応する公開鍵および秘密鍵をそれぞれ記憶する。例えば、鍵管理部１７１ｂは、ユーザ環境１６１から秘密鍵の要求を受け付けた場合に、要求された秘密鍵を記憶している場合には、秘密鍵をユーザ環境１６１に送信し、要求された秘密鍵を記憶していない場合には、鍵発行部１７１ａに秘密鍵発行を要求したうえで、発行された秘密鍵をユーザ環境１６１に送信する。
　復号化部１７１ｃは、メッセージまたはメッセージに添付されるファイルの復号化の要求をユーザ端末（ユーザ環境１６１）から受け付けた場合には、鍵発行部１７１ａによって発行された秘密鍵を用いて、メッセージまたはメッセージに添付されるファイルの復号化を行い、復号化したメッセージまたはファイルを復号化の要求を行ったユーザ端末（ユーザ環境１６１）に送信する。
［通信システムの処理手順］
　次に、図２～図４を用いて、通信システムが実行する通信処理の処理手順の一例について説明する。図２～図４は、第１の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。
　図２～図４に例示するように、メッセージ送信者は、ユーザ環境１６１を用いて、メッセージの受信者に宛てたメッセージを作成する。メッセージの本文乃至はメッセージの添付ファイルは、メッセージの送信者乃至はメッセージの受信者以外の第三者に閲覧されることを防ぐことを意図したものである。メッセージ送信者は、メッセージ乃至はメッセージの添付ファイル、メッセージ受信者の識別子（例えば受信者のメールアドレス）を指定する（Ｓ０００）。
　そして、ユーザ環境１６１のメッセージ送受信部１６１ａは、暗号化部１６１ｂに対して、メッセージ受信者の識別子を公開鍵とし、メッセージ乃至は添付ファイルの暗号化を要求する（Ｓ００１）。暗号化部１６１ｂは、公開鍵を用いて、メッセージ乃至は添付ファイルを暗号化し（Ｓ００２）、メッセージ送受信部１６１ａに応答する（Ｓ００３）。
　そして、ユーザ環境１６１のメッセージ送受信部１６１ａは、暗号化済メッセージ乃至は暗号化済添付ファイルを、メッセージサーバ１０１に送信する（Ｓ００４）。メッセージサーバ１０１は、メッセージ受信者が利用するユーザ環境１６１が所属するネットワーク２のメッセージサーバ１０２に対し、暗号化済メッセージ乃至は暗号化済添付ファイルを送信する（Ｓ００５）。
　続いて、ユーザ環境１６２のメッセージ送受信部１６２ａは、メッセージサーバ１０２に対して、新規メッセージの取得要求を行う（Ｓ０２１）。そして、メッセージサーバ１０２は、メッセージ受信者に宛てた新規メッセージの検索を行い（Ｓ０２２）、新規メッセージをユーザ環境１６２のメッセージ送受信部１６２ａに対し、新規メッセージを応答する（Ｓ０２３）。
　そして、ユーザ環境１６２のメッセージ送受信部１６２ａは、取得した新規メッセージにつき、暗号化済メッセージ、乃至は暗号化済添付ファイルの有無を確認（Ｓ０２４）し、新規メッセージに暗号化済メッセージ乃至は暗号化済添付ファイルが含まれる場合、攪乱部１６２ｃに対し、暗号化済メッセージ乃至は暗号化済添付ファイルの撹乱加工を要求する（Ｓ０２５）。攪乱部１６２ｃは、撹乱処理を行い（Ｓ０２６）、メッセージ送受信部１６２ａに対し、撹乱済暗号化済メッセージ、乃至は撹乱済暗号化済添付ファイルを応答する（Ｓ０２７）。
　続いて、ユーザ環境１６２のメッセージ送受信部１６２ａは、撹乱済暗号化済メッセージ、乃至は撹乱済暗号化済添付ファイルをクラウド鍵管理サーバ１７１上の暗号処理機能に送信し、復号を要求する（Ｓ０２８）。そして、復号化部１７１ｃは、クラウド鍵管理サーバ１７１上の鍵管理部１７１ｂに対し、メッセージ受信者に対応する秘密鍵を要求する（Ｓ０２９）。鍵管理部１７１ｂは、メッセージ受信者に対応する秘密鍵が検索できなかった場合（Ｓ０３０）、クラウド鍵管理サーバ１７１上の鍵発行機能に対し、秘密鍵発行を要求する（Ｓ０３１）。
　そして、鍵発行部１７１ａは、メッセージ受信者に対応する秘密鍵を発行し（Ｓ０３２）、鍵管理部１７１ｂに応答する（Ｓ０３３）。鍵管理部１７１ｂは、暗号処理機能に秘密鍵を応答する（Ｓ０３４）。復号化部１７１ｃは、秘密鍵を用いて、撹乱済暗号化済メッセージ、乃至は撹乱済暗号化済添付ファイルを復号し（Ｓ０３５）、撹乱済復号済メール、乃至は撹乱済復号済添付ファイルとして前記ユーザ環境１６２上のメッセージ送受信部１６２ａに応答する（Ｓ０３６）。
　続いて、ユーザ環境１６２のメッセージ送受信部１６２ａは、撹乱済メッセージ、乃至は撹乱済添付ファイルについて、攪乱部１６２ｃに対し撹乱解除を要求する（Ｓ０３７）。攪乱部１６２ｃは、撹乱解除処理を行い（Ｓ０３８）、メッセージ送受信部１６２ａに対し、撹乱済暗号化済メッセージ、乃至は撹乱済暗号化済添付ファイルを応答する（Ｓ０３９）。
［第１の実施形態の効果］
　このように、第１の実施形態に係る通信システムでは、ユーザ環境１６１が、他のユーザ環境１６２にメッセージを送信する場合に、メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、メッセージまたはメッセージに添付されるファイルを暗号化する。そして、ユーザ環境１６１が、メッセージまたはメッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する。また、ユーザ環境１６２が、他のユーザ環境１６１からメッセージを受信した場合には、メッセージまたはメッセージに添付されるファイルの復号化をクラウド鍵管理サーバ１７１に要求し、クラウド鍵管理サーバ１７１から復号化されたメッセージまたはファイルを受信する。
　つまり、通信システムでは、メール送信時にメッセージ受信者の識別情報に対応する公開鍵を入手して暗号化し、メール受信時にはクラウド鍵管理サーバ１７１に復号を要求することにより、ユーザ端末で鍵管理することなく、より簡単かつ安全なメッセージ送受信を行うことが可能である。例えば、第１の実施形態に係る通信システムでは、送信者のユーザ環境１６１及び受信者のユーザ環境１６２との間で、メッセージの受信者の識別情報に対応する公開鍵を用いて、メール本文乃至は添付ファイルを暗号化し、送受信することが可能である。また、第１の実施形態に係る通信システムでは、ユーザ端末側での鍵管理が最小化された、セキュアなメッセージ送受信機能を実現することが可能となる。
［第２の実施形態］
　以下の第２の実施形態では、ネットワーク上にディレクトリサーバを備え、属性ベース暗号を活用したポリシ設定を行う場合について説明する。なお、第１の実施形態と同様の構成および処理の説明は省略する。
　図５は、第２の実施形態に係る通信システムの構成例を示すブロック図である。図５に示すように、ネットワーク１、２は、それぞれディレクトリサーバ１１１、１１２を有する。
　ディレクトリサーバ１１１は、ネットワーク１上に存在するユーザに係る属性を管理し、他の機能の要求に応じて、該属性を提供する。ここでの属性とは、メールアドレス乃至はログイン時のアカウント名、などの該ユーザを識別する識別子、該ユーザが所属するグループや、役職、権限などを示す所属情報、およびその他の該ネットワーク内でユーザが本システムに限らず、ネットワーク上に接続されたシステムを利用するために必要な、氏名、等の個人に紐づく一般属情報、などが含まれる。
　ディレクトリサーバ１１１は、属性管理部１１１ａを有する。属性管理部１１１ａは、各ユーザの属性情報、ネットワーク内で管理されるメッセージ交換に必要な識別子、ネットワーク内で利用するユーザアカウントを記憶する。例えば、属性管理部１１１ａは、属性情報として、各ユーザの所属するグループや、役職、権限などを示す所属情報を記憶する。なお、ディレクトリサーバ１１１とディレクトリサーバ１１２とは同様の構成であり、ディレクトリサーバ１１２の説明は省略する。
　また、ユーザ環境１６１の暗号化部１６１ｂは、他のユーザ端末（ユーザ環境１６２）にメッセージを送信する場合に、メッセージの受信者の属性情報に対応する公開鍵を取得し、取得した公開鍵を用いて、メッセージまたはメッセージに添付されるファイルを暗号化する。
　例えば、暗号化部１６１ｂは、メッセージまたはメッセージに添付されるファイルに、復号可能な条件を示すポリシ情報を含めて暗号化するようにしてもよい。例えば、暗号化部１６１ｂは、既存の属性ベース暗号の方式を用いて、復号対象のメッセージ乃至はメールの添付ファイルに、復号条件のポリシを含め暗号化してもよい（例えば参考文献２参照）。
参考文献２：阿部、徳永、Ｍｅｈｄｉ、西巻、草川、「計算環境の変化に対応する暗号理論研究の最前線」、NTT技術ジャーナル、2020年2月
　ポリシの例としては、復号可能なユーザの識別子、復号可能な組織（ユーザの集合）の識別子、復号可能な時間、等がある。暗号化部１６１ｂは、復号対象のメッセージ乃至はメールの添付ファイルに、復号可能なユーザの識別子、復号可能な組織（ユーザの集合）の識別子、復号可能な時間等の条件を組み合わせたポリシ情報を埋め込んだ暗号文を生成する。
　鍵発行部１７１ａは、ユーザアカウントおよびユーザアカウントが所属する組織、役職等の所属情報、乃至は利用可能な時間帯、利用可能な端末乃至は利用可能なネットワーク、等の利用条件に紐付いて、メッセージ本文乃至は添付ファイルの暗号化、復号を可能とする鍵ペアを生成する。
　クラウド鍵管理サーバの復号化部１７１ｃは、受信者が持つ秘密鍵に埋め込まれた識別情報や、復号のタイミング等がポリシに適した場合に、復号化を行う。なお、ここでは、受信者が持つ秘密鍵には、例えば、ユーザの識別子、組織の識別子等が含まれる。
［通信システムの処理手順］
　次に、図６～図８を用いて、通信システムが実行する通信処理の処理手順の一例について説明する。図６～図８は、第２の実施形態に係る通信システムの処理の流れの一例を示すシーケンス図である。
　図６～図８に例示するように、ユーザ環境１６１のメッセージ送受信部１６１ａは、メッセージ送信者がメッセージ受信者に宛てたメッセージを作成する際に、ディレクトリサーバ１１１に対して、メッセージ受信者の識別子をもとに、メッセージ受信者の所属するグループや、役職、権限などを示す所属情報を要求する（Ｓ１０１）。
　そして、ディレクトリサーバ１１１は、メッセージ受信者の識別子をもとに、メッセージ受信者に係る所属情報を属性管理機能から取得し（Ｓ１０２）、所属情報をユーザ環境１６１のメッセージ送受信部１６１ａに提供する（Ｓ１０３）。
　続いて、ユーザ環境１６１のメッセージ送受信部１６１ａは所属情報に基づき、メッセージ送信者に対し、図９に例示するメッセージ暗号化ポリシの設定画面を提示し、メッセージ送信者に、暗号化ポリシを入力させる（Ｓ１０４）。図９は、暗号化ポリシの設定画面の一例を示す図である。
　ユーザ環境１６１のメッセージ送受信部１６１ａは、暗号化ポリシに基づき、暗号処理機能に対し、メッセージ乃至は添付ファイルの暗号化を要求する（Ｓ１０５）。そして、暗号化部１６１ｂは、メッセージ乃至は添付ファイルを、識別子ならびに暗号化ポリシを用いて、暗号化する（Ｓ１０６）。なお、以降の処理の流れは、第１の実施の形態と同様であるため、説明を省略する。
［システム構成等］
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。上記の実施形態の説明では、操作ログ取得装置上で表示された操作画面におけるイベントの発生を検知し、操作ログを記録する場合を説明したが、これに限定されるものではない。例えば、操作ログ取得装置が、他の端末上で表示された操作画面のイベントを検知し、操作ログを記録するようにしてもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、本実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
［プログラム］
　図１０は、通信プログラムを実行するコンピュータを示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１０４１に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１０６１に接続される。
　ハードディスクドライブ１０３１は、例えば、ＯＳ（Operating　System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、各装置の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０３１に記憶される。例えば、ユーザ端末における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。なお、ハードディスクドライブ１０３１は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３およびプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３およびプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例および運用技術等はすべて本発明の範疇に含まれる。
　１、２、４　ネットワーク
　１０１、１０２　メッセージサーバ
　１０１ａ、１０２ａ　メッセージ受信部
　１０１ｂ、１０２ｂ　メッセージＤＢ
　１０１ｃ、１０２ｃ　メッセージ送信部
　１６１、１６２　ユーザ環境
　１６１ａ、１６２ａ　メッセージ送受信部
　１６１ｂ、１６２ｂ　暗号化部
　１６１ｃ、１６２ｃ　攪乱部
　１７１　クラウド鍵管理サーバ
　１７１ａ　鍵発行部
　１７１ｂ　鍵管理部
　１７１ｃ　復号化部
　１６１０、１６２０　送信部
　１６１１、１６２１　要求部

Claims (6)

  1. 　メッセージの送信および受信を行うユーザ端末と、公開鍵と秘密鍵を管理するサーバ装置とを有する通信システムであって、
    　前記ユーザ端末は、
    　他のユーザ端末に前記メッセージを送信する場合に、前記メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルを暗号化する暗号化部と、
    　前記暗号化部によって前記メッセージまたは前記メッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する送信部と、
    　他のユーザ端末から前記メッセージを受信した場合には、前記メッセージまたは前記メッセージに添付されるファイルの復号化を前記サーバ装置に要求し、前記サーバ装置から復号化された前記メッセージまたは前記ファイルを受信する要求部と、
    　を有し、
    　前記サーバ装置は、
    　前記メッセージの受信者の識別情報に対応する秘密鍵を発行する鍵発行部と、
    　前記メッセージまたは前記メッセージに添付されるファイルの復号化の要求を前記ユーザ端末から受け付けた場合には、前記鍵発行部によって発行された秘密鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルの復号化を行い、復号化した前記メッセージまたは前記ファイルを前記復号化の要求を行ったユーザ端末に送信する復号化部と
    　を有することを特徴とする通信システム。
  2. 　前記ユーザ端末は、前記暗号化部によって暗号化された前記メッセージまたは前記メッセージに添付されるファイルを攪乱する攪乱部をさらに有することを特徴とする請求項１に記載の通信システム。
  3. 　前記暗号化部は、前記メッセージまたは前記メッセージに添付されるファイルに、復号可能な条件を示すポリシ情報を含めて暗号化することを特徴とする請求項１に記載の通信システム。
  4. 　他のユーザ端末にメッセージを送信する場合に、前記メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルを暗号化する暗号化部と、
    　前記暗号化部によって前記メッセージまたは前記メッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する送信部と、
    　他のユーザ端末から前記メッセージを受信した場合には、前記メッセージまたは前記メッセージに添付されるファイルの復号化をサーバ装置に要求し、前記サーバ装置から復号化された前記メッセージまたは前記ファイルを受信する要求部と
    　を有することを特徴とするユーザ端末。
  5. 　メッセージの送信および受信を行うユーザ端末と、公開鍵と秘密鍵を管理するサーバ装置とを有する通信システムによって実行される通信方法であって、
    　前記ユーザ端末が、他のユーザ端末に前記メッセージを送信する場合に、前記メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルを暗号化する暗号化工程と、
    　前記ユーザ端末が、前記暗号化工程によって前記メッセージまたは前記メッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する送信工程と、
    　前記ユーザ端末が、他のユーザ端末から前記メッセージを受信した場合には、前記メッセージまたは前記メッセージに添付されるファイルの復号化を前記サーバ装置に要求する要求工程と、
    　前記サーバ装置が、前記メッセージの受信者の識別情報に対応する秘密鍵を発行する鍵発行工程と、
    　前記サーバ装置が、前記メッセージまたは前記メッセージに添付されるファイルの復号化の要求を前記ユーザ端末から受け付けた場合には、前記鍵発行工程によって発行された秘密鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルの復号化を行い、復号化した前記メッセージまたは前記ファイルを前記復号化の要求を行ったユーザ端末に送信する復号化工程と
    　を含むことを特徴とする通信方法。
  6. 　他のユーザ端末にメッセージを送信する場合に、前記メッセージの受信者の識別情報に対応する公開鍵を取得し、取得した公開鍵を用いて、前記メッセージまたは前記メッセージに添付されるファイルを暗号化する暗号化ステップと、
    　前記暗号化ステップによって前記メッセージまたは前記メッセージに添付されるファイルが暗号化されたメッセージを他のユーザ端末に送信する送信ステップと、
    　他のユーザ端末から前記メッセージを受信した場合には、前記メッセージまたは前記メッセージに添付されるファイルの復号化をサーバ装置に要求し、前記サーバ装置から復号化された前記メッセージまたは前記ファイルを受信する要求ステップと
    　をコンピュータに実行させることを特徴とする通信プログラム。
PCT/JP2021/022218 2021-06-10 2021-06-10 通信システム、ユーザ端末、通信方法および通信プログラム WO2022259494A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2021/022218 WO2022259494A1 (ja) 2021-06-10 2021-06-10 通信システム、ユーザ端末、通信方法および通信プログラム
JP2023526784A JPWO2022259494A1 (ja) 2021-06-10 2021-06-10
US18/567,784 US20240146513A1 (en) 2021-06-10 2021-06-10 Communication system, user terminal, communication method, and communication program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/022218 WO2022259494A1 (ja) 2021-06-10 2021-06-10 通信システム、ユーザ端末、通信方法および通信プログラム

Publications (1)

Publication Number Publication Date
WO2022259494A1 true WO2022259494A1 (ja) 2022-12-15

Family

ID=84425079

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/022218 WO2022259494A1 (ja) 2021-06-10 2021-06-10 通信システム、ユーザ端末、通信方法および通信プログラム

Country Status (3)

Country Link
US (1) US20240146513A1 (ja)
JP (1) JPWO2022259494A1 (ja)
WO (1) WO2022259494A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005500740A (ja) * 2001-08-13 2005-01-06 ザ ボード オブ トラスティーズ オブ ザ リーランド スタンフォード ジュニア ユニバーシティ Ｉｄベース暗号化および関連する暗号手法のシステムおよび方法
JP2006319457A (ja) * 2005-05-10 2006-11-24 Ntt Data Corp 暗号化通信システム、秘密鍵発行装置、および、プログラム
WO2015008607A1 (ja) * 2013-07-18 2015-01-22 日本電信電話株式会社 復号装置、復号能力提供装置、それらの方法、およびプログラム
JP2018180408A (ja) * 2017-04-19 2018-11-15 日本電信電話株式会社 暗号処理方法、暗号処理システム、暗号化装置、復号装置、プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005500740A (ja) * 2001-08-13 2005-01-06 ザ ボード オブ トラスティーズ オブ ザ リーランド スタンフォード ジュニア ユニバーシティ Ｉｄベース暗号化および関連する暗号手法のシステムおよび方法
JP2006319457A (ja) * 2005-05-10 2006-11-24 Ntt Data Corp 暗号化通信システム、秘密鍵発行装置、および、プログラム
WO2015008607A1 (ja) * 2013-07-18 2015-01-22 日本電信電話株式会社 復号装置、復号能力提供装置、それらの方法、およびプログラム
JP2018180408A (ja) * 2017-04-19 2018-11-15 日本電信電話株式会社 暗号処理方法、暗号処理システム、暗号化装置、復号装置、プログラム

Also Published As

Publication number Publication date
JPWO2022259494A1 (ja) 2022-12-15
US20240146513A1 (en) 2024-05-02

Similar Documents

Publication Publication Date Title
JP4571865B2 (ja) 識別ベースの暗号化システム
US9917828B2 (en) Secure message delivery using a trust broker
US20080098237A1 (en) Secure e-mail services system and methods implementing inversion of security control
KR20210137073A (ko) 블록체인 기반 보안 이메일 시스템
Mont et al. A flexible role-based secure messaging service: Exploiting IBE technology for privacy in health care
KR20200027921A (ko) 멀티-홉 변환 암호화를 통한 그룹들에 대한 직교 액세스 제어
US7877594B1 (en) Method and system for securing e-mail transmissions
US20090271627A1 (en) Secure Data Transmission
US20170279807A1 (en) Safe method to share data and control the access to these in the cloud
US20070288746A1 (en) Method of providing key containers
US9665731B2 (en) Preventing content data leak on mobile devices
WO2005091579A1 (en) Secure email service
JP2011530248A (ja) 暗号化されたメッセージ交換のための方法及び装置
WO2005099352A2 (en) Secure data transmission
JP4434680B2 (ja) 電子メール処理装置用プログラム
Sharma et al. A comprehensive review on encryption based open source cyber security tools
KR102413497B1 (ko) 보안 전자 데이터 전송을 위한 시스템 및 방법
CN109194650B (zh) 基于文件远距离加密传输系统的加密传输方法
WO2022259494A1 (ja) 通信システム、ユーザ端末、通信方法および通信プログラム
EP4144041A1 (en) Method and apparatus for end-to-end secure sharing of information with multiple recipients without maintaining a key directory
WO2022259495A1 (ja) 通信システム、ユーザ端末、通信方法および通信プログラム
US11736462B1 (en) Hybrid content protection architecture for email
JP2009503963A (ja) メッセージの伝送方法およびシステム、ならびにそれに適した暗号鍵発生器
Hudnall et al. Implementing secure e-mail on the open internet with MailTrust
Sanamrad et al. My Private Google Calendar and GMail.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21945168

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023526784

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18567784

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE