JP2021051738A - Id in access management system, additional information management system, and program thereof - Google Patents

Abstract

To disclose confidential information only to members who share the content thereof, and manage the information by setting rights for each of the members to edit or browse the information.SOLUTION: A confidential information management program causes a computer to implement: a function of dividing a store file including confidential information into a description part including descriptions on the store file, a right part indicating users who can access the store file and access rights of the users, an editing part indicating users who can edit the confidential information, and a content part including the confidential information, and defining access levels indicating access rights to access each of the parts; and a function of applying hybrid encryption to each part of the store file in accordance with the access levels.SELECTED DRAWING: Figure 2

Description

There are various ways individuals can manage confidential information such as passwords, and 1Password (https://1password.com/jp/) and LastPass (https: /) and LastPass (https://1password.com/jp/) and LastPass (https://1password.com/jp/) and LastPass (https://1password.com/jp/) and LastPass (https://1password.com/jp/) password management services are available to enhance its convenience. /www.lastpass.com/en), iCloud keychain (https://developer.apple.com/documentation/security/keychain_services), etc. are provided. However, there are cases where confidential information such as passwords is shared not only by individuals but also by groups. For example, there is a case where an account of a certain service is shared and used within a group.

International Publication No. 2019/163040

1Password, [online], [Search September 13, 2020], Internet <https://1password.com/jp/> LastPass, [online], [Search September 13, 2020], Internet <https://www.lastpass.com/en> iCloud keychain, [online], [Search September 13, 2020], Internet <https://developer.apple.com/documentation/security/keychain_services>

When sharing confidential information such as passwords within a group, everyone must keep the same password, so either use the password management service described above, or make a note on shared storage or a shared website. The means of leaving it is taken.

If you manage your password by yourself like the former, you must update it when the password is updated, and there is a risk that it will be leaked to the outside in the procedure of sharing the password. It accompanies.

With the latter method of leaving notes on storage or websites, confidential information may be unintentionally seen by members who should not know the information.

The present invention has been made in view of the above problems, and the contents can be known only to the members who should share the contents of the confidential information, and the information is set by setting editing and viewing authority for each member. The purpose is to be able to carry out management. Furthermore, the purpose is to enable a secure confidential information management service by including a mechanism that allows a third party to verify whether the information has been tampered with without knowing its contents. To do.

The confidential information management program according to an embodiment of the present invention gives a computer a store file containing confidential information, a description unit including a description of the store file, and a user who can access the store file and an authority to indicate the access right of the user. A function that defines an access level that indicates the access right to each part, and a store file, is divided into a part, an editorial part that indicates a user who can edit confidential information, and a content part that includes confidential information. A function to apply hybrid encryption according to the access level is realized in each part.

According to the present invention, the contents can be known only to the members who should share the contents of the confidential information, and the information can be managed by setting the editing and viewing authority for each member. It becomes possible to do.

Configuration diagram of a system that shares and manages confidential information Store file configuration diagram Process flow diagram for reading store files

In the present embodiment, the contents can be known only to the members who should share the contents of the confidential information, and the information management can be performed by setting the editing and viewing authority for each member. .. Furthermore, by including a mechanism that allows a third party to verify whether the information has been tampered with without knowing its contents, a secure confidential information management service can be realized.

In this embodiment, a confidential information management system having the following features and a method thereof are shown.
-The store file that manages confidential information is divided into a Description part, a Permission part, an Editors part, and a Contents part, and users who can access each part are defined, and hybrid encryption is performed according to the definition.
-The main body of the secret information is saved in the Contents section, and hybrid encryption is performed using the public keys of all users who can access the information.
-In addition, by assigning the electronic signature of the last updater and the user ID of the signer to each part, it is possible to detect tampering and confirm whether the store file is created and edited according to the access authority.
-It is possible to set the access authority of owner, editor, readOnly and validator, describe the information in the Permission part, and check whether the store file is created and edited according to the access authority.
-In order to make it possible for a third party who does not share confidential information to be a verification server, a validator is set so that the parts other than the Contents part can be decrypted, and the store file is operated (created and edited) correctly. To be able to check and manage the latest version of the store file.

The confidential information management program according to the present embodiment provides a computer with a store file containing confidential information, a description unit including a description of the store file, a user who can access the store file, and an authority unit indicating the access right of the user. The editorial department that shows the users who can edit the confidential information and the content department that contains the confidential information are divided into a function that defines the access level that indicates the access right to each part, and each part of the store file. A function that performs hybrid encryption according to the access level is realized.

Further, in the confidential information management program according to the present embodiment, each part of the store file may include the user identification information of the last updater and the electronic signature.

Further, in the confidential information management program according to the present embodiment, the access right may include an owner, an editor, a viewer, and a verifier.

Further, in the confidential information management program according to the present embodiment, in the hybrid encrypted store file, the verifier can view the description part, the authority part, and the editorial part, and cannot see the content part. be able to.

The system configuration diagram is shown in FIG. In FIG. 1, the functions of this embodiment are implemented in the application and the verification server. On the other hand, a component called public key management is a function for managing public keys corresponding to user names (email addresses, etc.), and is the "access control system and program" filed in Patent Document 1 and PKI (Public Key Infrastructure). ), Etc. may be used.

The terms related to this embodiment are defined below.
<Definition of terms>
・ Confidential information record → A group of information that stores confidential information (URL, user name, password, common key, etc.) and describes it in a format such as JSON. ・ Store file → Multiple confidential information records and access Information about rights is encrypted and collected in one file-User-> Person who can (can) operate the store file-Verification server-> Check the health of the store file on behalf of the user, or check the latest version of the file Server to store → Like the user, it has a user name and a public key pair (stored by the public key management function)
・ Owner
→ Users / creators who can perform CRUD (Create, Read, Update, Delete) operations, access right control, and complete destruction of confidential information records.
→ It is also the user owner who created the store file (it is just an owner on the app)
・ Editor
→ A user who can perform CRUD (Create, Read, Update, Delete) operations of confidential information records, and access right control is not possible.
→ User / validator who can only perform R (Read) operation of confidential information record
→ With the authority of the verification server, it is possible to read other than secret information records ・ Order of authority (validator is out of the frame)
→ owner>editor> readOnly

<Application Example (Case 1)>
In this embodiment, the creator creates a store file and writes confidential information in the application shown in FIG. In addition, the owner, editor, and readOnly user types are set for other users, and the setting information is also stored in the store file (creator shall have owner authority). When saving the store file, the hybrid encryption process described later is performed. Save the encrypted store file in a shared folder, etc. so that related parties (users set to owner, editor, readOnly) can retrieve the file. Even if the store file is obtained, it cannot be decrypted by anyone other than the person concerned, so the contents cannot be viewed.

In addition to browsing, the person who obtained the store file can also add, overwrite, and delete confidential information to hybrid-encrypt the file again. However, whether the access authority is properly protected (whether the readOnly user has edited the confidential information or access authority, or the editor access authority has not been edited), and the contents of the file have been tampered with. The next user to access the file must confirm that this is not the case. If the access authority is not protected, the store file is destroyed.

<Application Example (Case 2)>
In the above (Case 1), the store file was saved in a shared folder, but in this case the correct store file may be lost because it can only be verified later whether the access right is protected. To prevent this, a separate method such as using a generation-manageable backup is required.

In order to solve this problem, the verification server shown in FIG. 1 may be introduced. The verification server is a function that stores the store file, but before storing it, it checks whether the store file is correct and whether it has been tampered with. In order to confirm, it is necessary to confirm the meta information in the store file described later, so when creating the store file, the creator specifies the validation server as a validator and sets that information in the store file. .. Then, the store file is subjected to hybrid encryption so that the validator can also be decrypted. However, since the verification server is a third party and the confidential information itself must not be known, the confidential information part is encrypted so that it cannot be decrypted by the validator. The verification server receives such store files and keeps only the legitimate ones as the latest version. In addition, the verification server returns the store file according to the request from the user.

<About store files>
Multiple secret information is bundled and stored in a store file. As shown in FIG. 5, the store file is composed of four parts, "Description", "Permission", "Editors", and "Contents" (the first three are collectively referred to as meta information). Each part has its own access level, and whether or not the contents can be viewed or edited depends on the authority of the user. The information and access levels included in each part are as follows.

-Description part-> Describe what kind of information the store file has, who created it when, etc.-> Information to be included: Document ID, creator user name, creation time, description-> Information to be included: Last User name of updater and digital signature by last updater → Access level: ReadOnly or higher and validator can be viewed ・ Permission part → List which user has which access right → Information to be included: Document ID
→ Information to be included: List the user names of owner, editor, and readOnly → Information to be included: User name of the last updater and digital signature by the last updater → Access level: Only those with owner authority can view / edit it can. Validator can be viewed ・ Editors section → Contents section lists editable user names, but by separating it from the Permission section, it is possible to prevent the editor from setting access rights → Information to be included: Document ID
→ Information to be included: List the user names that can view Contents → Information to be included: User name of the last updater and electronic signature by the last updater → Access level: Only those with authority of editor or higher can view and edit. You can also browse validators ・ Contents section → Stores confidential information. It can contain multiple confidential information.
→ Information to include: Document ID
→ Information to be included: Confidential information group → Information to be included: User name of the last updater and electronic signature by the last updater → Access level: Can be viewed by those with readOnly or higher authority → Access level: Editor or higher authority You can edit things → Access level: Validator cannot be viewed

Each of the above parts is expressed in a format that can describe the data structure in an extended form of key-value such as JSON (JavaScript Object Notation) and YAML (Yet Another Markup Language). Editing is an operation of adding, deleting, or modifying the information of the item. Document ID is a unique identifier for each store file. For example, UUID (https://tools.ietf.org/html/rfc4122) is used. The above-mentioned validator searches for the store file by Document ID and responds to the store file acquisition request. The Document ID is included not only in the Description part but in all parts in order to detect unauthorized operations that can replace the Permission part etc. with the contents of another file (about the normality confirmation method). Will be described later). It is necessary to use an identifier that can identify the user, such as an e-mail address, as the user name, and to be able to search for the public key from the public key management function with the same identifier. FIG. 2 illustrates the structure of the store file. The figure also shows an example in which the Description part is described in JSON.

In this embodiment, each of these parts is hybrid-encrypted (https://en.wikipedia.org/wiki/Hybrid_cryptosystem) using the public key of a user who has viewing authority.

Hybrid encryption means that information is encrypted by a common key encryption method (encrypted data), and the common key is encrypted with the public key of a user who can view the information (encrypted key), and the encrypted data. This is a method of generating an encrypted text that is a set of encrypted keys. It is also possible to create a set of encrypted keys for multiple users. For example, in order to make it visible only to two users, A and B, the original information X is encrypted with the common key K (the encrypted data is Enc (K, X)), and then K is used. Encrypt with A's public key Pa and B's public key Pb (the data are PubEnc (K, Pa) and PubEnc (K, Pb), respectively). The common key K is randomly generated each time it is encrypted, and is thrown away only once. Hybrid-encrypted data is a set of Enc (K, X), PubEnc (K, Pa), and PubEnc (K, Pb). Since A has the private key Sa corresponding to the public key Pa and B has the private key Sb corresponding to the public key Pb, the common key K is extracted from the hybrid encrypted data and X is decrypted using that key. it can.

The following shows which user's public key is used for hybrid encryption by each part.
-Description part-> readOnly, editor, owner, validator (that is, use the public key of all parties and verification server)
・ Permission part → owner, validator
・ Editors section → editor, owner, validator
・ Contents section → readOnly, editor, owner (use the public key of all parties except the verification server)

<Processing flow when reading a store file and how to check its normality>
When reading the store file, check the normality of each part, and finally check the overall consistency. If even one confirmation fails, the store file is destroyed. The processing flow is shown in FIG.

In the confirmation process of the normality of each part, the following confirmation is performed. The part described as a non-confirmed item is an explanation for reference, and it is not necessary to confirm the item.

-Description part-> Confirmation item: Decryptable If it cannot be decrypted, it is not a readOnly user and there is no point in accessing it, so discard it-> Confirmation item: Signature verification-Permission part-> Non-confirmation item: Only owner and validator can be decrypted. The user who cannot decrypt is not abnormal, only the access right cannot be changed.
→ Confirmation item: Signature verification / Editors section → Non-confirmation item: Only the owner, editor, and validator can be decrypted, so the user who cannot decrypt can only change the access right, and it is not abnormal.
→ Confirmation item: Signature verification / Contents section → Confirmation item: Decryptable (however, validator does not have to be decryptable)
If it cannot be decrypted by anything other than validator, it is abnormal and is discarded. → Signature verification

In the overall consistency confirmation process, the following confirmation is performed.
-The Document IDs of the Description, Permission, Editors, and Contents sections must all match.-The signature verification keys of the Description, Permission, and Editors sections must be the same.-The Description, Permission, and Editors sections The user type of the signer is owner-The user type of the signer in the Contents section is editor or owner

<Processing when writing / saving a store file>
If the owner changes the Description part or Permission part (and the Editors part accordingly), the entire meta information is re-encrypted and the signature of each part is updated. When performing hybrid encryption, obtain the public key of all members + the validator when using it from the public key management function (Fig. 1).

If the editor or owner edits the confidential information (that is, the Contents part), the Contents part is re-encrypted. Obtain the public key based on the list of user names written in the Editors section and perform hybrid encryption. Also update the signature.

If you edit only either the meta information or the confidential information, the unedited one reuses the original encrypted data as it is.

The store file generated in this way is sent to a shared folder or verification server for storage.

<Delete the store file of the verification server>
As mentioned above, the verification server has the role of checking the health of the store file and storing the latest file. When deleting a store file, only a user with owner authority should be able to do it. Therefore, when the verification server receives a delete request with a Document ID, it does not immediately delete the store file pointed to by the Document ID, but whether the requesting user is specified as owner in the store file. To confirm. If it is the owner, it accepts the deletion request and deletes the store file, but if it is not the owner, it discards the deletion request.

According to this embodiment, the contents can be known only to the members who should share the contents of the confidential information, and the information management can be performed by setting the editing and viewing authority for each member. It becomes possible to. Furthermore, by including a mechanism that allows a third party to verify whether the information has been tampered with without knowing its contents, it is possible to realize a secure confidential information management service. Become.

Claims (5)

On the computer
Editing a store file containing confidential information, indicating a description unit containing a description of the store file, a user who can access the store file, an authority unit indicating the access right of the user, and a user who can edit the confidential information. A function of defining an access level indicating the access right to access each part by dividing into a part and a content part containing the confidential information, and
A function to apply hybrid encryption to each part of the store file according to the access level, and
Confidential information management program to realize. The confidential information management program according to claim 1, wherein each part of the store file includes a user identification information of the last updater and an electronic signature. The confidential information management program according to claim 1 or 2, wherein the access right includes an owner, an editor, a viewer, and a verifier. The third aspect of the present invention, wherein in the hybrid-encrypted store file, the verifier can view the description unit, the authority unit, and the editorial unit, and cannot view the content unit. Confidential information management program. The computer
Editing a store file containing confidential information, indicating a description unit containing a description of the store file, a user who can access the store file, an authority unit indicating the access right of the user, and a user who can edit the confidential information. It is divided into a part and a content part containing the confidential information, and for each part, an access level indicating the access right to access each part is defined.
Hybrid encryption is applied to each part of the store file according to the access level.
Confidential information management method.

Images