Diskless clients, servers and their programs

The diskless client system securely authenticates in environments with mass users by using a unique encryption key for hardware processing and another for software, ensuring key secrecy and enhancing security.

JP7673868B2Active Publication Date: 2025-05-09NIPPON TELEGRAPH & TELEPHONE CORP
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
JP2024500904
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-02-21
Publication Date
2025-05-09
Estimated Expiration
2042-02-21

AI Technical Summary

Technical Problem

Existing diskless client systems face challenges in authenticating terminals securely in environments with mass users or third parties, such as home gateways and radio base stations, due to difficulties in managing and protecting encryption keys.

Method used

The system employs a diskless client that stores a unique first encryption key securely and uses a second encryption key for software processing, ensuring that the first encryption key remains unreadable externally. This involves a network connection information acquisition mechanism, a boot file acquisition unit, and a shared disk access unit that authenticate and encrypt connections using these keys.

Benefits of technology

This approach allows for safe authentication of diskless clients in environments exposed to mass users or third parties, maintaining the secrecy of encryption keys and enhancing security and ease of key management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007673868000001
    Figure 0007673868000001
  • Figure 0007673868000002
    Figure 0007673868000002
  • Figure 0007673868000003
    Figure 0007673868000003
Patent Text Reader

Abstract

This diskless client (2) comprises: an encryption key storage means (20) for preliminarily storing a key A so as to be unreadable from the outside; a network connection information acquisition means (21) for acquiring, from a server (3), network connection information and the address of a boot file; a boot file acquisition means (22) for acquiring a boot file that corresponds to the address and a key B; a boot means (23) for booting by using the boot file; and a shared disk access means (24) for accessing a shared disk of the server (3) via an encrypted connection.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to a diskless client, a server and a program thereof. To Regarding. [Background technology]

[0002] Conventionally, network computers that use software that utilizes remote disks, such as NFS (Network File System), are known (Non-Patent Document 1). Diskless client systems that use PXE (Preboot Execution Environment), a network boot specification, are also known (Non-Patent Documents 2 and 3). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Network computer, [online], Wikipedia, [searched on February 3, 2022], Internet, <URL:https: / / ja.wikipedia.org / wiki / %E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF> [Non-Patent Document 2] What is PXE boot? How PXE boot works, [online], [searched on February 3, 2022], Internet,<URL:http: / / www.putise.com / architecture / pxe-boot> [Non-Patent Document 3] About PXE boot and Kickstart technology, [online], [searched on February 3, 2022], Internet,<URL:https: / / docs.oracle.com / cd / E26854_01 / em.121 / b66837 / appdx_pxeboot.htm> Summary of the Invention [Problem to be solved by the invention]

[0004] The above-mentioned conventional technology is based on the premise that it is used in a LAN (Local Area Network), that is, that the diskless client and the network are trustworthy. Therefore, it is difficult to use the above-mentioned conventional technology in an environment where mass users or third parties may have access, such as a home gateway or a wireless base station. Specifically, with the above-mentioned conventional technology, terminal authentication of diskless clients becomes an issue in an environment where mass users or third parties may have access.

[0005] The present invention has been made in consideration of the above-mentioned points, and an object of the present invention is to securely authenticate diskless clients in an environment where mass users or third parties may have access to the system. [Means for solving the problem]

[0006] The diskless client of the present invention is a diskless client that accesses a shared disk of a server, and is characterized in that it comprises: an encryption key storage means for pre-storing a first encryption key unique to each diskless client so that it cannot be read from the outside; a network connection information acquisition means for requesting a network connection to the server and acquiring network connection information and an address of a boot file from the server in response to the request; a boot file acquisition means for performing authentication with the server using the first encryption key to establish an encrypted connection and acquiring a boot file corresponding to the address and a second encryption key different from the first encryption key via the encrypted connection; a boot means for booting using the boot file acquired by the boot file acquisition means; and a shared disk access means for performing authentication with the server using the second encryption key to establish an encrypted connection and accessing the shared disk of the server via the encrypted connection. Effect of the Invention

[0007] According to the present invention, diskless clients can be securely authenticated in an environment where there is a possibility of contact with mass users or third parties. [Brief description of the drawings]

[0008] [Figure 1] FIG. 4 is a sequence diagram showing the operation of the diskless client authentication system according to the embodiment. [Diagram 2] 1 is a block diagram showing a configuration of a diskless client according to an embodiment. [Diagram 3] FIG. 2 is a block diagram showing a configuration of a server according to the embodiment. [Figure 4] 4 is a flowchart showing a network connection method according to the embodiment. [Diagram 5] 4 is a flowchart illustrating a network opening method according to an embodiment. [Figure 6] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of a server according to the embodiment. [Figure 7] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of a diskless client according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] <Diskless client authentication system> Next, an embodiment of the present invention (hereinafter, referred to as "the present embodiment") will be described. FIG. 1 is a sequence diagram showing the operation of the diskless client authentication system 1 according to this embodiment.

[0010] In the diskless client authentication system 1, when a diskless client 2 boots, a server 3 authenticates the diskless client 2, and the authenticated diskless client 2 accesses a shared disk of the server 3.

[0011] As shown in Fig. 1, the diskless client authentication system 1 includes a diskless client 2 and a server 3. In the diskless client authentication system 1, the diskless client 2 and the server 3 are connected via a network such as the Internet. Although Fig. 1 shows only one diskless client 2, there may be multiple diskless clients.

[0012] Typically, an encryption key is used as a means of authentication and communication encryption. When using a diskless client 2 as a home gateway or wireless base station, the contents of the encryption key must not be known to third parties, nor to the user. If the contents of the encryption key were known to the user, a terminal not covered by the contract could be made into a diskless client 2. Therefore, the user must not be able to read the encryption key, and the encryption key must be kept secret within the hardware so that it cannot be read from outside.

[0013] Hereinafter, this encryption key is referred to as key A (first encryption key). This key A is assumed to be an encryption key of a general public key cryptosystem (for example, RSA). That is, in the diskless client authentication system 1, the diskless client 2 secretly manages a private key of the public key cryptosystem as key A, and distributes a public key of the public key cryptosystem to the server 3 in advance.

[0014] The boot of the diskless client 2 is made up of three steps: a hardware (firmware) processing step S1 of acquiring environmental information such as an IP address, a boot file acquisition step S2, and a software processing step S3 of accessing a shared disk.

[0015] In steps S1 and S2 of the hardware processing, there is no problem with authentication and encryption of communications using key A, but key A cannot be used for authentication and encryption of communications in step S3. As mentioned above, being able to use key A in step S3 of the software processing means that the software can read key A in the hardware, and the contents of key A will become known to the user. Therefore, in the software processing, an encryption key different from key A in the hardware processing will be used.

[0016] Hereinafter, the other encryption key will be referred to as key B (second encryption key). Key B can be a general encryption key such as a public key encryption key or a common key encryption key (e.g., AES).

[0017] In the IP address and other environmental information acquisition procedure S1, when the server 3 receives an IP address request of DHCP (BOOTP: BOOTstrap Protocol) (step S10), it generates a key B (step S11). Then, the server 3 transmits network connection information such as an IP address, a subnet mask, and a gateway, and an address of a boot file to the diskless client 2 (step S12).

[0018] The boot file refers to a file (for example, a root file system) required to boot the diskless client 2. The address of the boot file indicates the path of the server 3 where the boot file is stored.

[0019] In a procedure S2 for acquiring a boot file, the diskless client 2 is authenticated using key A, and an encrypted connection is established between the diskless client 2 and the server 3 (step S20). The diskless client 2 then requests a boot file from the server 3 via the encrypted connection (step S21), and acquires the boot file and key B from the server 3 (step S22).

[0020] The diskless client 2 boots using the boot file acquired from the server 3 (step S23).

[0021] In the shared disk access procedure S3, the diskless client 2 is authenticated using key B, and an encrypted connection is established between the diskless client 2 and the server 3 (step S30). The diskless client 2 then requests access to the shared disk from the server 3 via the encrypted connection (step S31), and after receiving an OK response from the server 3, accesses the shared disk (steps S32 and S33).

[0022] <Diskless client> The diskless client 2 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing the configuration of the diskless client 2 according to this embodiment.

[0023] The diskless client 2 accesses the shared disk of the server 3, and as shown in Fig. 2, includes an encryption key storage means 20, a network connection information acquisition means 21, a boot file acquisition means 22, a boot means 23, and a shared disk access means 24. In Fig. 2, the network is abbreviated as NW.

[0024] The encryption key storage means 20 stores in advance a key A unique to each diskless client 2 so that the key A cannot be read from the outside. An example of this encryption key storage means 20 is a tamper-resistant device such as a trusted platform module (TPM). In this embodiment, the encryption key storage means 20 stores a private key of a public key cryptosystem as key A. For example, key A may be written to the encryption key storage means 20 when the diskless client 2 is manufactured.

[0025] The network connection information acquisition means 21 requests a network connection to the server 3 (step S10 in FIG. 1). This network connection request is a request for an IP address by "DHCP REQUEST" or the like. In response to the request, the network connection information acquisition means 21 acquires network connection information such as an IP address, a subnet mask, and a gateway, as well as an address of a boot file, from the server 3 (step S12 in FIG. 1). Then, the network connection information acquisition means 21 outputs the acquired address of the boot file to the boot file acquisition means 22.

[0026] The boot file acquisition means 22 uses key A of the encryption key storage means 20 to perform authentication with the server 3 and establish an encrypted connection (step S20 in FIG. 1). For example, the boot file acquisition means 22 establishes transport using a procedure of TCP (Transmission Control Protocol)+TLS (Transport Layer Security) or QUIC+TLS. The boot file acquisition means 22 also requests a boot file from the server 3 via the encrypted connection, and acquires a boot file corresponding to the address and key B from the server 3 (steps S21 and S22 in FIG. 1). The boot file acquisition means 22 then outputs the acquired boot file to the boot means 23, and outputs key B to the shared disk access means 24.

[0027] The boot means 23 boots using the boot file acquired by the boot file acquisition means 22. For example, in the case of a Linux (registered trademark) kernel, the boot means 23 may mount the shared disk using NFS and specify an option to make the mounted file system the root file system.

[0028] The shared disk access means 24 uses the key B acquired by the boot file acquisition means 22 to perform authentication with the server 3 and establish an encrypted connection (step S30 in FIG. 1). For example, the shared disk access means 24 establishes transport using the TCP+TLS or QUIC+TLS procedure. The shared disk access means 24 then requests the server 3 to connect to the shared disk via the encrypted connection, and accesses the shared disk of the server 3 (steps S31 to S33 in FIG. 1).

[0029] <Server> The server 3 will be described with reference to Fig. 3. Fig. 3 is a block diagram showing the configuration of the server 3 according to this embodiment.

[0030] As shown in FIG. 3, the server 3 includes a network connection request determination means 30, a network connection information transmission means 31, an encryption key generation means 32, a boot file transmission means 33, a shared disk access control means 34, a shared disk 35, a network open request determination means 36, an encryption key destruction means 37, a network open means 38, and an encryption key storage means 39.

[0031] The network connection request determination means 30 determines whether or not a network connection has been requested by the diskless client 2. If the network connection request determination means 30 determines that a network connection has been requested by the diskless client 2, it commands the network connection information transmission means 31 to transmit network connection information.

[0032] In response to a network connection request from the diskless client 2, the network connection information transmitting means 31 transmits network connection information and an address of a boot file to the diskless client 2. In this embodiment, the network connection information transmitting means 31 transmits the network connection information and the address of a boot file to the diskless client 2 in accordance with a command from the network connection request determining means 30.

[0033] The encryption key generation means 32 generates a key B that is different from the key A that has been distributed in advance. In this embodiment, the encryption key generation means 32 generates the key B, which is a disposable key for each DHCP session, by a general public key cryptosystem or a common key cryptosystem. The encryption key generation means 32 then stores the generated key B and an association between the diskless client 2 that has requested a network connection and the key B in the encryption key storage means 39. This association is, for example, information that associates the IP address of the diskless client 2 that has requested a network connection with the key B.

[0034] 2, the boot file transmission means 33 performs authentication with the diskless client 2 using a pre-distributed key A to establish an encrypted connection. Then, the boot file transmission means 33 transmits the boot file corresponding to the address and key B of the encryption key storage means 39 to the diskless client 2 via the encrypted connection.

[0035] 2, the shared disk access control means 34 uses the key B to perform authentication with the diskless client 2 and establish an encrypted connection. Then, the shared disk access control means 34 allows the diskless client 2 to access the shared disk 35 via the encrypted connection. In this way, the shared disk access control means 34 controls access to the shared disk 35 by the diskless client 2.

[0036] The shared disk 35 is a recording device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) that stores shared files used by the diskless clients 2. For example, the shared file is a disk image file that represents a Linux (registered trademark) file system. This shared file may be common to the diskless clients 2, or may be individual depending on the hardware configuration of the diskless clients 2.

[0037] The network open request determination means 36 determines whether or not a network open request has been made by the diskless client 2. For example, a network open request is to release the IP address assigned to the diskless client 2 by "DHCP RELEASE", lease timer timeout, or a command from the server 3. If the network open request determination means 36 determines that a network open request has been made by the diskless client 2, it commands the encryption key destruction means 37 to destroy key B.

[0038] The encryption key destroying means 37 destroys the association between the diskless client 2 that has requested network opening and the key B, and destroys the key B. In this embodiment, the encryption key destroying means 37 destroys (deletes) the key B of the diskless client 2 and the association between the diskless client 2 and the key B from the encryption key storage means 39 in accordance with a command from the network opening request determination means 36.

[0039] The network opening means 38 releases the diskless client 2 that has requested network opening from the network. In this embodiment, the network opening means 38 releases the IP address that has been assigned to the diskless client 2 that has requested network opening.

[0040] The encryption key storage means 39 is a storage device such as an HDD or SSD that stores the key B and the association between the diskless client 2 and the key B.

[0041] <Network connection method> A network connection method in which the server 3 connects the diskless client 2 to the network will be described with reference to Fig. 4. Fig. 4 is a flowchart showing the network connection method according to this embodiment.

[0042] 4, in step S100, the network connection request determination means 30 determines whether or not there is an IP request event. This IP request event is an event that indicates a network connection request from the diskless client 2, such as a "DHCP REQUEST."

[0043] If there is an IP request event (Yes in step S100), the server 3 proceeds to the process of step S110. If there is no IP request event (No in step S100), the server 3 proceeds to the process of step S140.

[0044] In step S110, the network connection information transmitting means 31 performs a predetermined DHCP-related IP request process (network connection process). This DHCP-related IP request process is a process of transmitting network connection information and the address of a boot file to the diskless client 2.

[0045] In step S120, the encryption key generating means 32 generates a key B. In step S130, the encryption key generation means 32 stores in the encryption key storage means 39 the key B and the association between the key B and the diskless client 2 that has requested the network connection.

[0046] In step S140, the server 3 determines whether or not to end the process. For example, when the server 3 detects the occurrence of an asynchronous event that instructs the end, such as the reception of SIGTERM, the server 3 determines to end the process.

[0047] If the process does not end (No in step S140), the server 3 returns to the process in step S100.

[0048] <How to open the network> A network opening method in which the server 3 opens the diskless client 2 from the network will be described with reference to Fig. 5. Fig. 5 is a flowchart showing the network opening method according to this embodiment.

[0049] 5, in step S200, the network release request determination means 36 determines whether or not there is an IP release event. This IP release event is an event that indicates a network release request from the diskless client 2, such as "DHCP RELEASE", lease timer timeout, or a command from the server 3.

[0050] If an IP release event has occurred (Yes in step S200), the server 3 proceeds to the process of step S210. If there is no IP release event (No in step S200), the server 3 proceeds to the process of step S240.

[0051] In step S210, the encryption key destroying means 37 destroys from the encryption key storage means 39 the association between the diskless client 2 that has requested network opening and the key B. In step S 220 , the encryption key discarding means 37 discards the key B from the encryption key storage means 39 .

[0052] In step S230, the network releasing means 38 performs a predetermined DHCP-related IP releasing process (network releasing process). This DHCP-related IP releasing process is a process for releasing the IP address assigned to the diskless client 2.

[0053] In step S240, the server 3 determines whether or not to end the process. For example, when the server 3 detects the occurrence of an asynchronous event that instructs the end, such as the reception of SIGTERM, the server 3 determines to end the process.

[0054] If the process does not end (No in step S240), the server 3 returns to the process in step S200.

[0055] <Hardware configuration> For example, the server 3 according to this embodiment is realized by a computer 900 having a configuration as shown in FIG.

[0056] 6 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the server 3 according to this embodiment. The computer 900 has a CPU (Central Processing Unit) 901, a ROM (Read Only Memory) 902, a RAM (Random Access Memory) 903, an HDD (Hard Disk Drive) 904, an input / output I / F (Interface) 905, a communication I / F 906, and a media I / F 907.

[0057] The CPU 901 operates based on a program stored in the ROM 902 or the HDD 904, and performs control by each functional unit in Fig. 2. The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started up, programs related to the hardware of the computer 900, and the like.

[0058] The CPU 901 controls an input device 910 such as a mouse or a keyboard, and an output device 911 such as a display or a printer, via an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911.

[0059] The HDD 904 stores programs executed by the CPU 901 and data used by the programs, etc. The communication I / F 906 receives data from other devices (not shown, for example, a maintenance terminal, etc.) via a communication network (for example, the network 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0060] The media I / F 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0061] For example, when the computer 900 functions as the server 3 according to this embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 903 to realize the functions of the server 3. Furthermore, the HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program relating to a target process from the recording medium 912. Additionally, the CPU 901 may read a program relating to a target process from another device via a communication network (network 920).

[0062] Moreover, for example, the diskless client 2 according to this embodiment is realized by a computer 900A having a configuration as shown in FIG.

[0063] 7 is a hardware configuration diagram showing an example of a computer 900A that realizes the functions of the diskless client 2 according to this embodiment. This computer 900A is similar to the computer 900 in FIG. 6 except that it has a tamper-resistant device 913 instead of the HDD 904, so a description thereof will be omitted.

[0064] <Effects> The effects of the diskless client and server according to the present invention will now be described. The diskless client 2 accesses the shared disk of the server 3, and is characterized by comprising: an encryption key storage means 20 that pre-stores a unique key A for each diskless client 2 so that it cannot be read from the outside; a network connection information acquisition means 21 that requests a network connection to the server 3 and acquires network connection information and an address of a boot file from the server in response to the request; a boot file acquisition means 22 that uses key A to authenticate with the server 3 and establishes an encrypted connection, and acquires a boot file corresponding to the address and key B different from key A via the encrypted connection; a boot means 23 that boots using the boot file acquired by the boot file acquisition means; and a shared disk access means 24 that uses key B to authenticate with the server 3 and establishes an encrypted connection, and accesses the shared disk of the server 3 via the encrypted connection.

[0065] In this way, according to the diskless client 2, the key A used in the hardware processing and the key B used in the software processing are separated, and the key A is managed secretly so that it cannot be read by the software processing. As a result, the diskless client 2 can be safely authenticated in an environment where it may be touched by mass users or third parties.

[0066] Furthermore, in the diskless client 2, the encryption key storage means 20 is characterized in that it stores, as the key A, a private key of a public key encryption system.

[0067] This makes it easy to manage keys because, as long as the private key of the diskless client 2 is not stolen, the diskless client 2 can be securely authenticated even if the public key distributed to the server 3 is stolen.

[0068] Furthermore, in the diskless client 2, the encryption key storage means 20 is a tamper-resistant device.

[0069] This significantly reduces the possibility that the private key of diskless client 2 will be stolen.

[0070] The server 3 has a shared disk 35 accessed by the diskless client 2, and is characterized by comprising: a network connection information transmitting means 31 which transmits network connection information and the address of a boot file to the diskless client 2 in response to a network connection request from the diskless client 2; an encryption key generating means 32 which generates a key B different from a previously distributed key A; a boot file transmitting means 33 which uses the key A to perform authentication with the diskless client 2 to establish an encrypted connection and transmits the boot file corresponding to the address and the key B via the encrypted connection; and a shared disk access control means 34 which uses the key B to perform authentication with the diskless client 2 to establish an encrypted connection and allows the diskless client 2 to access the shared disk 35 via the encrypted connection.

[0071] In this way, the server 3 separates the key A used in the hardware processing from the key B used in the software processing, and manages the key A secretly so that it cannot be read by the software processing. As a result, the diskless client 2 can be securely authenticated in an environment where it may be touched by mass users or third parties.

[0072] In addition, in the server 3, the boot file transmission means 33 is characterized in that it uses, as the key A, a public key of a public key cryptosystem.

[0073] This makes it easy to manage keys because, as long as the private key of the diskless client 2 is not stolen, the diskless client 2 can be securely authenticated even if the public key distributed to the server 3 is stolen.

[0074] Furthermore, the diskless client 2 requires almost no on-site work and is easy to set up. Furthermore, since the diskless client 2 does not have a storage device such as a fault-prone HDD, the device failures are reduced, and maintenance costs such as equipment repair and replacement can be reduced. Furthermore, the diskless client 2 can share (duplicate) the environment by accessing the same disk area of ​​the server 3. For example, the diskless client 2 is suitable for cloud infrastructure, home gateways, wireless base stations, and the like. In particular, home gateways and wireless base stations have a large number of pieces of equipment and are installed in various locations, such as inside homes and buildings, so the diskless client 2 has great advantages in these applications.

[0075] <Modification> Although the embodiment has been described in detail above, the present invention is not limited to the above-described embodiment, and includes design modifications and the like within the scope of the present invention.

[0076] In the above embodiment, the first encryption key of the public key cryptosystem is used, but the present invention is not limited to this. For example, the first encryption key of the common key cryptosystem may be used.

[0077] In the above embodiment, the server is described as an independent piece of hardware, but the present invention is not limited to this. For example, the present invention can be realized by a program for making hardware resources such as a CPU, memory, and hard disk of a computer function as the above-mentioned server. This program may be distributed via a communication line, or may be written on a recording medium such as a CD-ROM or a flash memory and distributed. [Explanation of symbols]

[0078] 1 Diskless Client Authentication System 2 Diskless Clients 20 Encryption key storage means 21 Network connection information acquisition method 22 How to obtain boot files 23 Boot Method 24 Shared Disk Access Method 3 Server 30 Network connection request determination means 31 Network connection information transmission means 32 Encryption key generation means 33 Boot file transmission method 34 Shared disk access control means 35 Shared Disk 36 Network release request determination means 37 Cryptographic key destruction method 38 Network Opening Methods 39 Encryption key storage means

Claims

1. A diskless client that accesses a shared disk of a server, an encryption key storage means for storing a first encryption key unique to each of the diskless clients in advance so that the first encryption key cannot be read from outside; a network connection information acquiring means for requesting a network connection to the server and acquiring network connection information and an address of a boot file from the server in response to the request; a boot file acquisition means for establishing an encrypted connection by performing authentication with the server using the first encryption key, and acquiring a boot file corresponding to the address and a second encryption key different from the first encryption key via the encrypted connection; a boot means for booting using the boot file acquired by the boot file acquisition means; a shared disk access means for performing authentication with the server using the second encryption key to establish an encrypted connection and for accessing a shared disk of the server via the encrypted connection; A diskless client comprising:

2. 2. The diskless client according to claim 1, wherein the encryption key storage means stores a private key of a public key cryptosystem as the first encryption key.

3. 3. The diskless client according to claim 1, wherein the encryption key storage means is a tamper-resistant device.

4. A server having a shared disk accessed by a diskless client, a network connection information transmitting means for transmitting network connection information and an address of a boot file to the diskless client in response to a network connection request from the diskless client; an encryption key generating means for generating a second encryption key different from a first encryption key that has been distributed in advance; a boot file transmission means for establishing an encrypted connection by performing authentication with the diskless client using the first encryption key, and transmitting a boot file corresponding to the address and the second encryption key via the encrypted connection; a shared disk access control means for performing authentication with the diskless client using the second encryption key to establish an encrypted connection and allowing the diskless client to access the shared disk via the encrypted connection; A server comprising:

5. 5. The server according to claim 4, wherein the boot file transmission means uses a public key of a public key cryptosystem as the first encryption key.

6. A program for causing a computer to function as the server according to claim 4 or 5.

Citation Information

Patent Citations

  • Program for installing software, storage medium and device

    JP2007141102A

  • Network access control system, terminal, address application device, terminal system authentication device, network access control method and computer program

    JP2007299136A

  • Method and system for securely installing software over a network

    US20050028154A1

  • Analysis, recovery and repair of devices attached to remote computing systems

    US20150067399A1

  • Ensuring the integrity of remote boot client data

    US6189100B1