HTML5 Webook

31/84

to the predened format that enables relays between QKD links and the provision of safe keys to various kinds of applications; on top of the key-management layer, the ap-plication layer is placed, where various kinds of communi-cation applications using safe keys are developed in line with information theory. We call the combination of the quantum layer and the key-management layer the QKD platform. Below, we describe in detail the conguration of the key-management layer. Each “trusted node” is equipped with a key management agent (KMA) which is in charge of collection and management of keys from QKD links. Each KMA, interconnected with other KMAs via an au-thenticated communication path, is in charge of key-relay-ing. At the time of key-relaying, other additional information such as a key-ID attached when the key is created is transmitted.e QKD platform has a key management server (KMS), which is placed in a trusted node. KMS, in charge of the collection from KMAs of QKD-link information such as the error rate, key creation rate, or the stored key amount, determines the key-relay route using the stored key amount and key creation rate, issues a route change order on the occasion of a drop in the stored key amount or an incident, and furthermore, monitors the life-cycle of the keys stored in KMAs, and issues an order to KMA for removing a key that lives longer than a predened time from birth.A key supply agent (KSA) is a device placed in each node, which works as an interface device from the QKD platform to the application layer, supplies a key in the format the application species, makes a record of the key ID, the application type and the date of supply, and deliv-ers such information to the KMS.One of the most signicant ideas on the QKD platform is that the boundary of responsibility is set between the QKD platform and the application layer. erefore, only very limited information crosses the border—no means is available in the application to access any data but the key supplied by the QKD platform, and at the same time, the QKD platform has no means to access any data belonging to the application layer such as what kinds of contents are being handled in an application. So, such strict authority separation in terms of access to devices belonging to the other side ensures the essential protection of network se-curity.TabT1　Protocol and communication distance / loss in Tokyo QKD NetworkProtocolTransmissionLength （km）Loss （dB）NEC-0BB84 with decoy50 （Spooled fiber NICT premise）10NEC-1BB84 with decoy22 （field installed 95% areal line）13ToshibaBB84 with decoy45 （field installed 50% areal line）14.5NTT-NICTDPS-QKD90 （field installed 50% areal line）28.6GakushuinCV-QKD2 （NICT premise）2SeQureNetCV-QKD2 （NICT premise）2FiF4Processing time in three phases (registration, pre-computation and reconstruction. (a) Processing time dependency on mersenne prime index size at data size of 46 kilobytes. (b) Processing time dependency on file size at the mersenne prime of 244497-1.1000100001000000510152025Processing time (sec)Index of Mersenne prime (n of 2n-1) regisntration pre-computation reconstructionfile size: 46 kbyte1E+041E+051E+061E+07020406080100Processing time (sec)File size (byte) registration pre-computation reconstructionMersenne prime: 244497-1 (a)(b)273-2 Information Theoretically Secure Distributed Storage with QKD and Password-Authenticated Secret Sharing