Method and system which authenticate certainly service specialized user of remote service interface to storage medium

The present invention generally relates to the authentication of a user who intends to remotely access a device. Specifically, the invention states that a service representative is an authorized service representative with the appropriate access level (eg, service, support, or enhancement) to service the storage medium remotely. It relates to methods and systems for authenticating service personnel for remote access to storage media in a non-verifiable manner.

Currently, service interfaces for remote service personnel exist for enterprise-level tape controller products. This interface is invoked by a service representative establishing a working connection to the tape controller over a private network. Authentication of a service person requires verification that the service person is an authorized service person with the proper access level to remotely service the tape medium controlled by the controller. In particular, for authentication, the service person obtains the authentication key from the tape controller via the private network, and the service person obtains the system password corresponding to the authentication key from the access server via the public network. Sequentially involved in obtaining and providing the system password to the tape controller over a private network, thereby gaining the desired access to the tape medium.

<p>The challenge for the computer industry is to have service personnel to remotely access storage media over a private network, and to remotely access any type of device controlled by a server over a single network. It is to improve the user convenience and processing efficiency of the above authentication with respect to any other person who desires, and an object of the present invention is to provide methods and systems for that purpose.</p>

<p> One embodiment of the present invention is a method for allowing a first client and a second client to establish authentication for a user who intends to remotely access a device. The method is that the first client provides the first set of personal information about the user to the first server over the first network, and the first client provides the encrypted user certificate from the first server. Receiving over the first network (note that the encrypted user certificate includes encrypting at least one personal attribute for the user corresponding to the first set of personal information by the first server). , The second client provides the encrypted user certificate to the second server over the second network, and the second client provides remote access information from the second server over the second network. (Note that the remote access information facilitates remote access to the device over the second network by the user based on the response to the verification of the encrypted user certificate by the second server. Includes).</p><p> A second embodiment of the present invention is a method for enabling a first server and a second server to authenticate a user who intends to remotely access a device connected to the second server in an operating relationship. is there. The method is that the first server receives the first set of user's personal information from the first client via the first network, and the first server receives the encrypted user certificate via the first network. (Note that the encrypted user certificate includes encrypting at least one personal attribute for the user corresponding to the first set of personal information by the first server. ), The second server receives the encrypted user certificate from the second client over the second network, and the second server receives the remote access information over the second client through the second client. (Note that the remote access information facilitates remote access to the device over the second network by the user based on the response to the verification of the encrypted user certificate by the second server. Includes).</p><p> A third embodiment of the present invention provides a means for receiving a first set of personal information about a user from a first client via a first network and an encrypted user certificate via the first network. A means to provide to one client (note that the encrypted user certificate includes encrypting at least one personal attribute about the user corresponding to the first set of personal information by the first server. ), Means for receiving encrypted user certificates from the second client over the second network, and means for providing remote access information to the second client over the second network, ( Note that the remote access information facilitates remote access by the user to the device over the second network based on the response to the verification of the encrypted user certificate by the second server). Is.</p><p> A fourth embodiment of the present invention is a server that includes a processor and a memory that stores instructions that can be operated by the processor to provide the user with an encrypted user certificate. These instructions include an encrypted user that includes a step of receiving a set of personal information about the user from the client over the network and an encrypted version of at least one personal attribute of the user corresponding to the set of user's personal information. It performs a step of generating a certificate in response to receiving a set of user's personal information and a step of providing the encrypted user certificate to a client over a network.</p><p> A fifth embodiment of the present invention is a server including a processor and a memory for storing instructions that can be operated by the processor and providing remote access information to a user. These instructions go to the step of receiving the user's encrypted user certificate from the client over the network, including the encrypted version of at least one of the user's personal attributes, and to the device under operational control by the server. The step of generating remote access information that facilitates remote access by the user based on the verification of the encrypted user certificate, and the step of providing the remote access information to the client over the network. To execute.</p><p> The above and other embodiments, objectives, features, and advantages of the present invention will become more apparent from the following detailed description of the various embodiments of the invention presented herein. The detailed description and drawings do not limit the scope of the invention and its equivalents as defined by the "Claims", but merely illustrate and illustrate the invention.</p>

FIG. 1 shows an exemplary operating environment for carrying out the present invention. Referring to FIG. 1, the present invention provides a reliable low-overhead user authentication device 60 that facilitates access by the user 10 to device 50 (eg, tape storage medium) up to X (X &amp; # 8805; 1). I will provide a. To this end, the user authentication device 60 includes a new and unique user authentication module 61 and a new and unique user authentication module 61 for embodying the various methods of the present invention, as will be described later in connection with FIGS. 2 to 6. Uses a unique user remote access module 62. Client 11 (eg, web browser) and certification server 30 (eg, web-based server) are physically connected to network 20 (eg, public network), which causes client 11 and certification server 30 to be hardware. Alternatively, it is possible to connect to the operating relationship in a general way, such as operating a user authentication module 61 that uses software or both. Note that module 61 uses hardware and / or software structurally configured to embody the flowchart 70 shown in FIG. 2 for the purpose of providing an encrypted user certificate to user 10. To do.

Further referring to FIG. 2, stage S72 of the flowchart 70 includes receiving the personal information PI1 provided by the user 10 via the network 20 to the module 61. The personal information PI 1 contains information about the user 10 that allows the module 61 to recognize the user 10, such as a user identification mark and a user password.

Stage S74 of Flowchart 70 involves module 61 generating one encrypted user certificate EUC based on one or more variables. In one embodiment, the following four variables can be utilized during Stage 74: The first variable is the personal information PI1 provided by user 10. The second possible variable contains one or more personal attributes of user 10 corresponding to personal information PI1 provided by user 10. The personal attribute is, for example, a personal attribute such as the access level of the user 10 for accessing the device 50 corresponding to the personal information about the user 10 in the form of a user identification mark and a user password. For such an example, module 61 can hold a file for user 10 that associates user 10's access level with a user identification mark and user password, thereby making module 61 It is possible to retrieve the access level of user 10 when the user identification mark and user password are received from user 10.

The third variable was related to accessing device 50, for example, a time stamp to facilitate the decision as to whether the access period of the encrypted user certificate EUC has expired. Contains one or more operational attributes. Another exemplary operational attribute is the need for user 10 to access device 50 remotely, for example, operational failure or malfunction by device 50 that requires remote service by user 10. It is an event identification mark corresponding to a sex-induced event.

The fourth variable is the encryption key EK, which is the public or private key associated with module 61 for the purpose of encrypting user authentication.

Module 61 is such encrypted based on personal information PI1, the personal attributes of user 10, operational attributes related to remote access to the device, or encryption key EK, or some of them. The technology for generating user certificates is endless. Therefore, the following description of an embodiment of stage S74 represented by flowchart 80 shown in FIG. 3 is not limited to the scope of stage S74.

Further referring to FIG. 3, stage S82 of Flowchart 80 includes module 61 processing personal information PI1 to retrieve user identification marks, user passwords, and user passphrases. The user identification mark and user password allow the module 61 to identify the user 10, while the user passphrase provides the module 61 with additional security.

Stage S84 of Flowchart 80 generates unencrypted user data in response to Module 61 being able to identify User 10 by a valid user passphrase during Stage S82. Including doing. In one embodiment of stage S84, module 61 generated (1) user identification indicator for user 10, (2) access level for user 10, and (3) unencrypted user data. Execute the create command to create the unencrypted user data sequentially configured from the time stamp, which specifies the time, as the string USERDATA1. The string USERDATA1 also includes (4) application-specific data for adding application-specific functionality to unencrypted user data, and (5) for example, the access period (the resulting encrypted user certificate). It is possible to include a period key that specifies (valid for that period) and one or more unique keys, such as a random key that contains random data to add additional security to the string USADATA1. is there. In addition, it limits the keys that maintain the user 10's inspection of remote connections, the keys that record the time required to service the device 50, and the systems that the user 10 can connect to the operational relationship through the client. It is also possible to use additional keys such as keys for, automatic search reports that match the user's 10 accounts, and keys for generating any relevant geographic attributes.

In the second embodiment of stage S84, module 61 generated (1) user identification mark for user 10, (2) user access level for user 10, and (3) unencrypted user data. An unencrypted user configured sequentially from a time stamp that specifies the time, and (4) an event identification mark that represents a notification of a particular event that has triggered the need for user 10 to access device 50 remotely. Run the create command to create the data as the string USERDATA2. The string USERDATA2 can further contain (5) application-specific data and (6) one or more unique keys as described above.

Stage S86 of Flowchart 80 includes the module 61 utilizing an encryption algorithm to encrypt unencrypted user data. In one embodiment of stage S86, module 61 utilizes the asymmetric encryption algorithms ACA (eg, Riverst-Shamir-Adleman and Rabin) from the secret encryption key EK and the unencrypted user data string USERDATA1. Run the create command to create the encrypted user data ENCDATA1. In the second embodiment of stage S86, module 61 utilizes the asymmetric encryption algorithm ACA to generate encrypted user data ENCDATA2 from the secret encryption key EK and the unencrypted user data string USERDATA2. Execute the create command to create.

Stage S88 involves module 61 converting encrypted user data into an encrypted user certificate using a further encryption algorithm. In one embodiment of stage S88, module 61 uses the symmetric encryption algorithm SCA (eg, XOR) to obtain the encrypted user certificate USERCERT1 from the user passphrase and encrypted user data ENCDATA1. Execute the create command to create. In the second embodiment of stage S88, module 61 creates an encrypted user certificate USERCERT2 from the user passphrase and encrypted user data ENCDATA2 using the symmetric encryption algorithm SCA. Flowchart 80 ends when stage S88 is complete.

Referring again to FIGS. 1 and 2, module 61 proceeds to stage S76 in flowchart 70 at the end of stage S74. Stage S76 includes module 61 providing the encrypted user certificate EUC to user 10 over network 20. In one embodiment, module 61 provides the encrypted user certificate EUC as USERCERT1 or USERCERT2 in Base64 format, thereby making the encrypted user certificate usable as text, which Allows users 10 to simplify operations such as copy / paste, save as text, and transfer via a modem.

Flowchart 70 ends when stage S76 is complete. Those skilled in the art will appreciate the various advantages of Flowchart 70 from the above description of Flowchart 70. In particular, the ability to customize a certain degree of certainty authentication of user 10 is (1) personal information of user 10, (2) personal attributes associated with user 10, and (3) remote to device 50 by user 10. Due to the application-specific nature and complexity of access-related operational attributes, (4) unencrypted user data structure, (5) private encryption key, and (6) encryption algorithms ACA and SCA. Based on. In addition, the above elements can be permanently configured for module 61, or periodically or sporadically replaced and / or modified according to application-specific policies associated with module 61. ..

Referring to FIG. 1, client 12 (eg, tape application) and equipment server 40 (eg, tape controller) are physically connected to network 21 (eg, private network), thereby client 12 and server 40. Can be connected to the behavioral relationship in a general way to operate the module 62. Note that module 62 is shown in FIG. 4 for the purpose of facilitating remote access to device 50 by user 10 based on the encrypted user certificate previously provided to user 10 by module 61. Use hardware and software configured to embody Flowchart 90.

Further referring to FIG. 4, stage 92 of Flowchart 90 includes module 62 receiving personal information PI2 and encrypted user certificate EUC provided by user 10 over network 21. Personal information PI2 provides information about user 10 that allows module 61 to identify user 10 (eg, user identification mark and user password) and the nature of remote access to device 10 that user 10 desires. Contains information to make a decision. Encrypted User Certificate EUC is the encryption of user 10's personal information, user 10's personal attributes, operational attributes related to user 10's remote access to device 50, application-specific security data, or one. Or it contains several unique keys or some of them.

Stage S94 of Flowchart 90 includes module 62 generating remote access information RAI based on one or more variables. In one embodiment, three variables are available during Stage S94: The first and second variables are the personal information PI2 and the encrypted user certificate EUC provided by user 10. The third variable is the public or private decryption key DK associated with module 62 to decrypt the encrypted user certificate.

The technology by which Module 62 generates remote access information based on personal information PI1, encrypted user certificate EUC, or decryption key DK or some of them is unlimited. Therefore, the following description of an embodiment of stage S94 represented by flowchart 90 shown in FIG. 6 is not limited to the scope of stage S94.

Further referring to FIG. 5, stage S102 of Flowchart 100 includes module 62 processing personal information PI2 to retrieve user identification marks, user passwords, user passphrases, and access level requests. The user identification mark and user password allow module 62 to identify user 10, while the user passphrase provides module 62 with additional security. The access level request allows module 62 to determine the nature of remote access to device 50 desired by user 10. In addition, module 62 decrypts the encrypted user certificate EUC when needed, for example when the encrypted user certificate EUC is in USERCERT1 format or USERCERT2 base64 format.

Stage S104 of Flowchart 100 includes module 62 utilizing an encryption algorithm to convert the encrypted user EUC into encrypted user data. In one embodiment of stage S108, module 62 uses the symmetric encryption algorithm SCA (see S88 in Figure 3) to encrypt user data from the user passphrase and the encrypted user certificate USERCERT1. Execute the create command to create ENCDATA1. In the second embodiment of stage S108, module 62 utilizes the symmetric encryption algorithm SCA (see S88 in Figure 3) to encrypt the user from the user passphrase and the encrypted user certificate USERCERT2. Execute the create command to create the data.

Stage S106 of Flowchart 100 involves module 62 using another encryption algorithm to decrypt the encrypted user data. In one embodiment of stage S106, module 62 utilizes the asymmetric encryption algorithm ACA (see S86 in Figure 3) to public decryption key DK and encrypted user data ENCDATA1 to unencrypted user. Execute the create command to create the data USERDATA1. In the second embodiment of stage S106, module 62 was encrypted from the public decryption key DK and the encrypted user data ENCDATA1 using the asymmetric encryption algorithm ACA (see S86 in Figure 3). Run the create command to create user data USERDATA2.

Stage S108 of Flowchart 100 includes module 62 validating unencrypted user data. In one embodiment, module 62 contains user 10's personal information, user 10's personal attributes, operational attributes related to user 10's remote access to device 50, application-specific security data, or unencrypted. Validate the unique keys listed in the cipher's user data or some of them. The technology by which module 62 authenticates user 10 during stage S108 is unlimited. Therefore, the following description of an embodiment of stage S108 represented by flowchart 110 shown in FIG. 6 is not limited to the scope of stage S108.

Further referring to FIG. 6, flowchart 110 is performed to authenticate user 10 based on the unencrypted user data string USERDATA1 and the unencrypted user data string USERDATA2, as described above. .. Stage S112 of Flowchart 110 indicates that the user ID provided by user 10 matches the USERID attributes listed in the unencrypted user data string USERDATA1 and the unencrypted user data string USERDATA2. Includes that module 62 verifies. In stage S114 of flowchart 110, the access level request provided by user 10 conforms to the access level attributes listed in the unencrypted user data string USERDATA1 and the unencrypted user data string USERDATA2. Includes that module 62 verifies that it does.

Stage S116 of Flowchart 110 notifies user 10 of a particular event in which the event IDs listed in the unencrypted user data string USERDATA2 have triggered the need for remote access to device 50 by user 10. Includes module 62 verifying that it matches the properly generated event ID for this purpose. Stage S116 cannot be applied to the unencrypted user data string USERDATA1.

Stage S118 of flowchart 110 shows the unencrypted user data string USERDATA1 and the unencrypted user data string USERDATA1 and the unencrypted time stamps listed in the unencrypted user data string USERDATA2. Includes module 62 verifying that it has an age less than the access period to the user data string USERDATA2. As mentioned above, access periods should be listed in the unencrypted user data string USERDATA1 and the unencrypted user data string USERDATA2, either as a unique key or based on the application-specific policy of Module 62. Is possible.

Stage S120 of Flowchart 110 includes module 62 setting up a local user account with a random password that is valid throughout the access period. The local user account and random password are formatted by module 62 when they need to be included in the remote access information RAI. Flowcharts 100 and 110 end upon completion of stage 120.

With reference to FIGS. 1 and 4 again, module 62 proceeds to stage S96 in flowchart 90 upon completion of stage S94. Stage S96 includes module 62 providing remote access information RAI to user 10 over network 21. Flowchart 90 ends when stage S96 is complete. Various advantages of the flowchart 90 from the foregoing description of the flowchart 90, in particular, Yoo for a reliable and of the device 50 in the form of low-overhead remote access capabilities to authenticate over The 10 will be apparent to those skilled in the art ..

In order to easily understand the complete authentication of the user 10 based on the principle of the present invention, the user 10 provides valid and accurate personal information and an encrypted user certificate with reference to FIGS. 2 and 4. Flowcharts 70 and 90 have been described in a practical manner based on the above. It is possible to terminate flowcharts 70 and 90 at any stage in response to User 10 providing invalid or inaccurate personal information and / or encrypted user certificates. It will be obvious to the trader.

Referring to FIGS. 1-6, in one practical embodiment, modules 61 and 62 (FIG. 1) are represented as software modules provided in the memory of servers 30 and 40 (FIG. 1), respectively. It is possible that the processors of the respective servers 30 and 40 can execute modules 61 and 62 to perform various operations of the present invention as in the examples shown in FIGS. 2-6. is there. Modules 61 and 62 can be written in any common programming language by those skilled in the art understanding the description of FIGS. 2-6 when they are incorporated as software modules.

With reference to FIG. 1, another operating environment for carrying out the present invention will be apparent to those skilled in the art by providing the operating environment as shown for ease of understanding of the present invention. For example, it embodies the operating environment where a wireline connection, a wireless connection, or a mixture thereof is embodied, as a client application on the same physical computer platform (eg, workstation) where clients 11 and 12 are embodied. The operating environment when this is done, or when networks 20 and 21 are separate and different virtual networks that exist on the same physical network.

With reference to Figures 3 and 5, a private encryption key (PEK) and a public decryption key (PDK) are selected, thereby embodying the asymmetric encryption algorithm ACA for ACA (PEK, ACA (PDK, data)). It is recommended that cryptography be equal to the realization of ACA (PDK, ACA (PEK, data)) with the same data. In addition, a private encryption key and a public decryption key are selected, thereby recommending that the ACA (any key, ACA (PEK | PDK, data) asymmetric encryption algorithm ACA implementation equals that data. In addition, any compromise of private encryption keys can trigger the replay and distribution of a pair of private encryption key and public decryption key for modules 61 and 62, respectively.

Although the disclosed embodiments of the present invention are considered to be preferred embodiments at this time, various modifications and modifications can be made without departing from the spirit and scope of the invention. The scope of the present invention is set forth in "Claims", and it is considered that the meaning of the equivalent and all modifications within the scope are included therein.

<figref num="1">It is a figure which shows the exemplary operating environment for carrying out this invention.</figref><figref num="2">It is a flowchart which shows the method of providing the encrypted user certificate according to one Embodiment of this invention.</figref><figref num="3">It is a flowchart which shows the method of generating the encrypted user certificate according to one Embodiment of this invention.</figref><figref num="4">It is a flowchart which shows the user apparatus access method according to one Example of this invention.</figref><figref num="5">It is a flowchart which shows the method of generating the access information according to one Example of this invention.</figref><figref num="6">It is a flowchart which shows the user authentication method according to one Example of this invention.</figref>