<<

. 8
( 9)



>>

device? One method to encode the data is so-called QR codes (quick response codes)
[9, 10, 11]
Figure 9.5 shows some QR codes which have been generated by use of the free
tool of KAYWA AG, Switzerland (http://qrcode.kaywa.com). The left one encodes




Fig. 9.5 QR codes
180 P. Schartner and C. Kollmitzer

the URL “www.secoqc.net,” the middle one encodes the text “SECOQC “ Develop-
ment of a Global Network for Secure Communication based on Quantum Crypto-
graphy,” and the right one encodes the ¬rst 236 characters of the ¬rst paragraph of
the Wikipedia page on QR codes (“http://en.wikipedia.org/wiki/QR Code”). These
sample QR codes correspond to about 77, 528, and 1.298 bits, respectively (∼5.5
bits per alphanumerical character).
According to Denso Wave Incorporated, QR codes “ which use Reed-Solomon
for error detection and error correction “ come with the following maximum data
capacity:

• 1.817 Kanji/Kana characters, or
• 4.296 alphanumeric characters, or
• 7.089 numeric only characters, or
• 2.953 bytes (8 bits each, so 23.624 bits in total).

Most PDA and Smartphone cameras come with a minimal focus distance of about
30“50 cm. This means that the LCD screen displaying the QR codes has to be in
similar distance to the camera (see the left side of Fig. 9.6 for a sketch of such a
system). In order to reduce the size of the key terminal, we could use the camera to
detect the presence or absence of light only (binary coding). In this case, the minimal
focusing distance doesn™t matter and we can shrink the size of the key terminal to a
minimum.
In order to overcome the reduced bandwidth of binary transmission, we could
split the camera image into several subsections (each detecting the presence/absence
of light) or we could use several colors like indicated in the right half of Fig. 9.6. In
both cases the bandwidth will be increased by 2n , where n is the number of sections
or colors, respectively. Additionally, the images are now much simpler than QR
codes and hence can be decoded much faster.



QKey-Station2
QKey-Station1




QAN
LED(s)
QAN

LCD-Display


Fig. 9.6 iPhone 3G at a key terminal
9 Quantum-Cryptographic Networks from a Prototype to the Citizen 181

9.2.2 Secure Storage
In our scenario, there is no online connection between the QAN and the mobile
device. So it is obvious that we have to securely store an appropriate amount of
key material within the mobile device over a longer period of time. So let us brie¬‚y
analyze some types of mobile devices with respect to secure storage:

• Laptops and Netbooks: Indisputably, these devices provide a huge storage capac-
ity, but they are quite clumsy and very hard to secure.
• PDAs and SmartPhones: These devices are rather handy and come with suf¬cient
memory, but are still quite hard to secure.
• Smart Cards: Smart Cards come with two ¬‚avors: smart cards (also known as
ICCs “ integrated circuit cards) and special secure memory cards.

“ Smart Cards or ICCs: By now, there are four standardized formats: ID-0
(credit card size), ID-00, ID-000 (plugin or SIM size), and Mini-UICC (about
half plugin-size). These cards can provide up to 1 GB of non-volatile memory
and most commonly come with a cryptographic co-processor (e.g., 2048 RSA
in 10 ms, AES in 10 μs). Besides these positive features, smart cards come
with a major disadvantage: that we need some type of special terminal in order
to connect them to a PC, Laptop, PDA, or SmartPhone.
“ Secure memory cards: Within memory cards, a special type of SD memory
crads (short SDCards [4]) is quite promising: the certgate SDCard [5]. This
SDCard (1 GB) is provided with a smart card microprocessor. Since this pro-
cessor can be used over the standard SDCard interface, no special reader is
needed.

Up to now, Personal Digital Assistants (PDAs) or SmartPhones which are
equipped with a smart card or some other security token (e.g., a certgate SDCard)
will ful¬ll our security requirements. It is obvious that this type of equipment is not
ideal (e.g., it is not unconditional secure), but it is available, quite cheap, widely
adopted and accepted by the customers.



9.2.3 Ef¬cient Key Usage

In the SECOQC design, a standard QBB node has three types of key buffers (called
KeyStores):

• In-KeyStore: Keys within this KeyStore are reserved for incoming messages of
the QBB network.
• Out-KeyStore: Keys within this KeyStore are reserved for outgoing messages of
the QBB network.
• Application KeyStore: Keys within this KeyStore are handed over to external
applications.
182 P. Schartner and C. Kollmitzer

QAN QAN
Free Keys Customer #1 Customer #2
Key IDs Keys Key IDs Keys Key IDs Keys
ID1 Key1 ID1,1 Key1,1 ID2,1 Key21
...
ID2 Key2 ID1,2 Key1,2 ID2,2 Key2,2
ID3 Key3 ID1,3 Key1,3 ID2,3 Key2,3
¦ ¦ ¦ ¦ ¦ ¦

(a) Free Keys (b) Customer/Application specific Keys

Fig. 9.7 Quantum access node keystore


In order to guarantee a minimum number of QKeys for special applications,
we would like to propose an additional component which divides the keys of the
Application KeyStore into two classes: so-called free keys and designated keys (see
Fig. 9.7. The IN- and OUT-buffer of the QBB node will remain reserved for internal
use (i.e., key forwarding).

• Free Keys: Free keys may be used for any purpose (i.e., encryption or authentica-
tion of any data type) and any receiver. After retrieval of the communication key
at the sender™s end, the system does not know the receivers address. So there are
at least two possible strategies:

1. The sender already knows the receiver (respectively, his address). Now, the
receiver can be informed by the system and the receiver can immediately
retrieve the communication key.
2. The sender does not want to send data right now, he simply wants to
get some keys for his local key storage. Now there can™t be done any-
thing in advance at the receiver™s end. The receiver has to wait for the
encrypted/authenticated message in order to identify the used key. Now he
can retrieve the key and decrypt/check the message.

• Designated Keys: If a sender retrieves a key reserved for a special receiver (or
purpose), the designated receiver can automatically be informed as soon as the
key has been retrieved by the sender. Hence, the receiver is able to fetch his key
at the moment, the sender requests it from the KeyStore.


9.3 Resumee

So far, the ¬eld of QKD has been analyzed from several different points of view.
Especially, networks have been in the center of research interest. With the SECOQC
demonstration in October 2008 it has been shown that networks based on QKD are
realizable, which changed the focus on the security research. On one hand there will
be growing interest on QKD-based applications and, on the other hand, we expect an
increasing research activity on the enhancement of already existing communication
infrastructures regarding a secured key exchange. In our opinion, transmission, stor-
9 Quantum-Cryptographic Networks from a Prototype to the Citizen 183

age, and usage of keys generated by QKD becomes the new emphasis of research
work.
In order to achieve an appropriate market throughput, QKD systems will have to
offer solutions for different security levels. Thereby, different areas must be covered,
e.g., QR codes offer the possibility of a fast, widely spread, and easy to use method
for applications of a lower security level.
From our point of view, QKD is a massive future topic. The research focus will
spread in the next years and not only the physical fundamentals will be examined
but also the aspects of applications will be more and more of interest. We think in
particular that scenarios with simple, easy to access interfaces, designed for a large
number of users such as telephone boxes or ATM-like systems, will be of strong
interest.



References
1. All´ aume, R., Bouda, J., Branciard, C., Debuisschert, T., Dianati, M., Gisin, N.,
e
Godfrey, M., Grangier, P., L¨ nger, T., Leverrier, A., L¨ tkenhaus, N., Painchault, P.,
a u
Peev, M., Poppe, A., Pornin, T., Rarity, J., Renner, R., Ribordy, G., Riguidel, M.,
Salvail, L., Shields, A., Weinfurter, H., Zeilinger, A.: SECOQC white paper on quantum
key distribution and cryptography (2007). http://www.citebase.org/abstract?id=oai:arXiv.org:
quant-ph/07%01168 173
2. All´ aume (Editing author), R., Bouda, J., Branciard, C., Debuisschert, T., Dianati, M.,
e
Gisin, N., Godfrey, M., Grangier, P., L¨ nger, T., Leverrier, A., L¨ tkenhaus, N., Painchault, P.,
a u
Peev, M., Poppe, A., Pornin, T., Rarity, J., Renner, R., Ribordy, G., Riguidel, M., Salvail, L.,
Shields, A., Weinfurter, H., Zeilinger, A.: Quantum key distribution and cryptography.
SECOQC White Paper (2007) 173
3. Assche, G., Cardinal, J., Cerf, N.: IEEE Trans. Inf. Theory 50, 394 (2004) 173
4. Association, S.: (2009). http://www.sdcard.org 181
5. Certgate: Certgate Secure Digital Card (2009). www.certgate.de 176, 181
6. Forum, N.: (2009). http://www.nfc-forum.org/home 177, 178
7. Haselsteiner, E., Breitfuss, K.: Security in near ¬eld communication (NFC). Hand-
out of Workshop on RFID Security RFIDSec06 (2006). http://events.iaik.tugraz.at/
RFIDSec06/Program/papers/002%20-%20Security%20in%20NFC.pdf 178
8. IdQuantique: (2009). http://www.idquantique.com 175
9. Inc., D.W.: QR-Code Standardization (2009). http://www.denso-wave.com/qrcode/
qrstandard-e.html
10. ISO: (2006). ISO/IEC 18004:2006 “ Information technology “ Automatic identi¬cation and
data capture techniques “ QR Code 2005 bar code symbology speci¬cation
11. ISO: (2009). ISO/IEC 18004:2006/Cor 1:2009
12. Monyk (Coordinator), C.: Development of a global network for secure communication based
on quantum cryptography. EC/IST Integrated Project SECOQC Contract No. 506813
(2004-2008) 173
13. Poppe, A., Fedrizzi, A., Ursin, R., B¨ hm, H.R., Lor¨ nser, T., Maurhart, O., Peev, M., Suda, M.,
o u
Kurtsiefer, C., Weinfurter, H., Jennewein, T., Zeilinger, A.: Practical quantum key distribution
with polarization entangled photons. Opt. Express 3865 12 (2008) 175
14. Poppe, A., Peev, M., Maurhart, O.: Outline Of The SECOQC quantum-key-distribution net-
work in Vienna. Int. J. Quantum Inf. 6(2) (2008) 174
15. SECOQC “ Development of a Global Network for Secure Communication based on Quantum
Cryptography: (2009). http://www.secoqc.net 173
184 P. Schartner and C. Kollmitzer

16. Sheet, I.P.F.: (2009). http://cordis.europa.eu/fetch?CALLER=PROJ IST&ACTION=D&RCN=
71407 174
17. Ursin, R., Tiefenbacher, F., Schmitt-Manderbach, T., Weier, H., Scheidl, T., Lindenthal, M.,
¨
Blauensteiner, B., Jennewein, T., Perdigues, J., Trojek, P., Omer, B., F¨ rst, M., Meyenburg, M.,
u
Rarity, J., Sodnik, Z., Barbieri, C., Weinfurter, H., Zeilinger, A.: Free-Space distribution of
entanglement and single photons over 144 km (2006) 178
Chapter 10
The Ring of Trust Model

C. Kollmitzer and C. Moesslacher




10.1 Introduction
The following chapter deals with a possible application of methods of quantum
cryptography to permit secure communication between parties in different archi-
tectures by establishing a Ring of Trust. The aim is to solve the problems of key
distribution with methods of quantum cryptography without being limited by their
transmission range. At the same time, a high level of security is obtained, which
is ensured by the use of corresponding cryptographic algorithms. The model is not
restricted to certain cryptographic algorithms. Therefore, it is possible to enlarge
a preexisting system with new cryptographic algorithms or to replace formerly
employed cryptographic algorithms with new ones.
The model presented here limits neither the number of communication parties
nor the maximum distance between the different parties. Quantum key distribution
(QKD) has now reached a stage of maturity which makes it possible to implement
QKD into existing infrastructures, for example, in medical information systems
(MIS), and thus enhances their security level signi¬cantly. Medical information
systems are a critical ¬eld because patient-related data and surgery data are both
con¬dential and a subject to legal restraints. Furthermore every kind of medical
data has to be highly available.
There also arise new services from this ¬eld which can only be implemented if a
secure transmission and storage of data can be guaranteed.




C. Kollmitzer (B)
Safety & Security Department, Quantum Technologies, AIT Austrian Institute
of Technology GmbH, Lakeside B01A 9020 Klagenfurt, Austria,
christian.kollmitzer@ait. ac.at; http://www.ait.ac.at
C. Moesslacher
Safety & Security Department, Quantum Technologies, AIT Austrian Institute of Technology
GmbH, Lakeside B01A, 9020 Klagenfurt, Austria, christian.moesslacher@gmx.net




Kollmitzer, C., Moesslacher, C.: The Ring of Trust Model. Lect. Notes Phys. 797, 185“210 (2010)
c Springer-Verlag Berlin Heidelberg 2010
DOI 10.1007/978-3-642-04831-9 10
186 C. Kollmitzer and C. Moesslacher

10.2 Model of the Point of Trust Architecture
Two communication parties who want to communicate can be in two different Trust
Zones, as shown in Fig. 10.1. In order to communicate they have to rely on a Point
of Trust they are assigned to. Each client is connected to its Point of Trust via a
quantum channel. All clients of a single Point of Trust form a Trust Zone. Different
Points of Trust are connected to each other either directly or via other Points of
Trust using either a public channel or a quantum channel. Also the different clients
are connected via a public channel, but in order to have a secure communication
beyond their Trust Zone they have to establish a session key via their Points of Trust
and the corresponding network.


Public channel;
Other points of trust




Point of Trust A Point of Trust B


Quantum channels Quantum channels


Trust Zone A Trust Zone B




Client A.1 Client A.2 Client A.n Client B.1 Client B.2 Client B.m




Public channel




Fig. 10.1 Point of Trust architecture with several Trust Zones

If both communication parties are within one Trust Zone, as shown in Fig. 10.2
(i.e., both are connected to the same Point of Trust) it is easy for them to establish a
secure communication via the assigned Point of Trust. But to be able to communi-
cate with both, communication parties inside and outside their own Trust Zone, they
can use the Ring of Trust architecture.


10.3 Communication in the Point of Trust Model

The following examples describe the secure communication between two clients.
These two clients are either in different Trust Zones, as outlined in 10.3.1.1 and
10.3.2.1, or in the same Trust Zone, as described in 10.3.1.2 and 10.3.2.2. Due to
10 The Ring of Trust Model 187

Fig. 10.2 Point of Trust
architecture with one Trust
Zone


Point of Trust


Quantum channels


Trust Zone




Client 1 Client 2 Client n




the new architecture presented in this chapter, it is no longer necessary for the two
legitimate communication parties to exchange keys over a secure channel. Yet, they
can still communicate at a high level of security.


10.3.1 Resource-Oriented Setup of Communication

Contrary to the speed-oriented setup as described in 10.3.2, both steps are triggered
by the initiator. Therefore, more steps must be carried out than in the speed-oriented
setup.

10.3.1.1 Point of Trust Architecture with Several Trust Zones
In this architecture, communication takes place between clients of different Trust
Zones. The participating Points of Trust must be trustworthy, i.e., they must have
exchanged a key. Such a network of Points of Trust can be set up in different ways,
e.g., in the form of a hierarchical model or a point-to-point model as shown in
Figs. 10.3 and 10.4. The form of communication between the respective Points of
Trust is not relevant for the function of the Point of Trust model.

Step 1: Initiation of communication
At the beginning of the communication the situation is given by the following con-
ditions. Client A.1 requests client B.2 to communicate and client A.1 and client B.2
are members of different Trust Zones.
The initialization of communication is shown in Fig. 10.5. The communication
steps are delineated subsequently.
188 C. Kollmitzer and C. Moesslacher

Fig. 10.3 Hierarchical model




Europe North America




Austria Canada




Vienna Toronto


Fig. 10.4 Point-to-Point
model


London Tokyo




Vienna Toronto


To initialize the communication client A.1 sends a request and transmits its data
(authenticity, authorization, accounting information, etc.) to Point of Trust A (I) in
order to be identi¬ed as part of Trust Zone A. Point of Trust A checks the data of
client A.1. After positive validation, the request for communication party client B.2
is transmitted to Point of Trust B (A1) that is responsible for the target, client B.2.
(Points of Trust A and B might be connected directly or via other Points of Trust).
Point of Trust B receives the request for communication between the communi-
cation parties client A.1 and client B.2 and requests the identi¬cation of client B.2 to
communicate (A2). Client B.2 receives the request and sends his data (authenticity,
10 The Ring of Trust Model 189




Client A.1 Point of Trust A Point of Trust B Client B.2



I

Request 1 A
1

Request 2 A
2

Request 3 A
3

Response 1
A
4

Request 4 A
5

Response 2
A
6

Response 3
A
7

Response 4


Fig. 10.5 Initiation of communication


authorization, accounting information, etc.) to Point of Trust B as response (A3) in
order to be identi¬ed as part of Trust Zone B. Point of Trust B receives the response
and checks the data of client B.2. After positive validation, the information relevant
to the communication is sent to client B.2 (A4), introducing the requesting commu-
nication party, client A.1.
Client B.2 con¬rms the request for communication from client A.1 and sends his
response to Point of Trust B (A5). Point of Trust B receives the con¬rming response
and forwards it to Point of Trust A (A6). Point of Trust A receives the con¬rming
response and forwards it to the requesting communication party, client A.1(A7).


Step 2: Setup of secure communication
The setup of secure communication is shown in Fig. 10.6. The communication steps
are delineated subsequently.
190 C. Kollmitzer and C. Moesslacher




Client A.1 Point of Trust A Point of Trust B Client B.2


I I I I
1 Generating Stream 1 2 3 Generating Stream 2 4

A
1

Stream 1 encrypted A
2

Stream 3 A
3

Session Key


Fig. 10.6 Setup of secure communication




Client A.1 and Point of Trust A are ready to communicate and generate Stream 1,
a shared stream generated by using quantum mechanical techniques, over a quantum
channel (I1 and I2). Analog, client B.2 and Point of Trust B are ready to communi-
cate and generate Stream 2 (I3 and I4).
Both communication parties have generated streams they share with their respec-
tive Points of Trust. Point of Trust A encrypts Stream 1 using a key shared with Point
of Trust B generating Stream 1 encrypted and transmits it to Point of Trust B (A1).
Point of Trust B receives Stream 1 encrypted and uses the key shared with Point
of Trust A to decrypt it. The reproduced Stream 1 is then encrypted by Stream 2
generating Stream 3 which is transmitted to client B.2 (A2).
Client B.2 receives Stream 3 and uses Stream 2, which is known to him, to
reproduce Stream 1. Stream 1 is subsequently established as the session key for
the communication parties, client A.1 and client B.2 (A3).


10.3.1.2 Point of Trust Architecture with One Trust Zone
Step 1: Initiation of communication
At the beginning of the communication the situation is given by the following con-
ditions. Client A.1 requests client A.2 to communicate and client A.1 and client A.2
are members of the same Trust Zone.
The communication steps for the initialization of communication are delineated
subsequently.
10 The Ring of Trust Model 191

To initialize the communication client A.1 sends a request and transmits his data
(authenticity, authorization, accounting information, etc.) to Point of Trust A in
order to be identi¬ed as part of Trust Zone A. Point of Trust A checks the data
of client A.1. After positive validation, Point of Trust A requests the identi¬cation
of client A.2 to communicate.
Client A.2 receives the request and sends his data (authenticity, authorization,
accounting information, etc.) to Point of Trust A as response in order to be identi¬ed
as part of Trust Zone A. Point of Trust A receives the response and checks the data of
client A.2. After positive validation, the information relevant to the communication
is sent to client A.2, introducing the requesting communication party, client A.1.
Client A.2 con¬rms the request for communication from client A.1 and sends his
response to Point of Trust A. Point of Trust A receives the con¬rming response and
forwards it to the requesting communication party, client A.1.


Step 2: Setup of secure communication
The communication steps to setup secure communication are delineated subse-
quently.
Client A.1 and Point of Trust A are ready to communicate and generate Stream 1,
a shared stream generated by using quantum mechanical techniques, over a quantum
channel. Analog, Stream 2 is generated between Point of Trust A and client A.2
which is ready to communicate too.
Both communication parties have generated streams they share with Point of
Trust A. Point of Trust A encrypts Stream 1 using Stream 2 to generate Stream 3.
Stream 3 is then transmitted to client A.2.
Client A.2 receives Stream 3 and uses Stream 2, which is known to him, to
reproduce Stream 1. Stream 1 is subsequently established as the session key for
the communication parties, client A.1 and client A.2.



10.3.2 Speed-Oriented Setup of Communication

Contrary to the resource-oriented setup as described in 10.3.1, the response of the
target, when requested to communicate, is not directly transmitted to the initia-
tor. Instead the target responds by taking the initiative in setting up secure com-
munication. In this way fewer steps are necessary, which speeds up the setup of
communication.


10.3.2.1 Point of Trust Architecture with Several Trust Zones
In this system, communication takes place between clients from different Trust
Zones. The respective Points of Trust must be trustworthy, i.e., they must have
exchanged a key. For information on different network models see 10.3.1.1.
192 C. Kollmitzer and C. Moesslacher

Step 1: Initiation of communication
At the beginning of the communication the situation is given by the following con-
ditions. Client A.1 requests client B.2 to communicate and client A.1 and client B.2
are members of different Trust Zones.




Client A.1 Point of Trust A Point of Trust B Client B.2



I

Request 1 A
1

Request 2 A
2

Request 3 A
3

Response 1
A
4

Request 4 A
5


Fig. 10.7 Initiation of communication



The initialization of communication is shown in Fig. 10.7. The communication
steps are delineated subsequently.
To initialize the communication client A.1 sends a request and transmits his data
(authenticity, authorization, accounting information, etc.) to Point of Trust A (I) in
order to be identi¬ed as part of Trust Zone A. Point of Trust A checks the data of
client A.1. After positive validation, the request for communication party client B.2
is transmitted to Point of Trust B (A1) which is responsible for the target, client B.2.
Point of Trust B receives the request for communication between the communi-
cation parties client A.1 and client B.2 and requests the identi¬cation of client B.2
to communicate (A2). Client B.2 receives the request and sends his data (authen-
ticity, authorization, accounting information, etc.) to Point of Trust B as response
(A3) in order to be identi¬ed as part of Trust Zone B. Point of Trust B receives the
response and checks the data of client B.2. After positive validation, the information
10 The Ring of Trust Model 193

relevant to the communication is sent to client B.2 (A4), introducing the requesting
communication party, client A.1.
Client B.2 con¬rms the request for communication from client A.1 and takes
initiative (A5).


Step 2: Setup of secure communication
The setup of secure communication is shown in Fig. 10.8. The communication steps
are delineated subsequently.
Client A.1 and Point of Trust A are ready to communicate and generate Stream 1,
a shared stream generated by using quantum mechanical techniques, over a quantum
channel (I1 and I2). Analog, client B.2, and Point of Trust B are ready to communi-
cate and generate Stream 2 (I3 and I4).
Both communication parties have generated streams they share with their respec-
tive Points of Trust. Point of Trust B encrypts Stream 2 using a key shared with Point
of Trust A generating Stream 2 encrypted and transmits it to Point of Trust A (A1).
Point of Trust A receives Stream 2 encrypted and uses the key shared with Point
of Trust B to decrypt it. The reproduced Stream 2 is then encrypted by Stream 1
generating Stream 3 which is transmitted to client A.1 (A2).
Client A.1 receives Stream 3 and uses Stream 1, which is known to him, to
reproduce Stream 2. Stream 2 is subsequently established as the session key for
the communication parties, client A.1 and client B.2 (A3).




Client A.1 Point of Trust A Point of Trust B Client B.2


I I I I
1 Generating Stream 1 2 3 Generating Stream 2 4

A
1

Stream 2 encrypted
A
2

Stream 3
A
3

Session Key


Fig. 10.8 Setup of secure communication
194 C. Kollmitzer and C. Moesslacher

10.3.2.2 Point of Trust Architecture with One Trust Zone
Step 1: Initiation of communication
At the beginning of the communication the situation is given by the following con-
ditions. Client A.1 requests client A.2 to communicate and client A.1 and client A.2
are members of the same Trust Zone.
The communication steps for the initialization of communication are delineated
subsequently.
To initialize the communication client A.1 sends a request and transmits his data
(authenticity, authorization, accounting information, etc.) to Point of Trust A in
order to be identi¬ed as part of Trust Zone A. Point of Trust A checks the data
of client A.1. After positive validation, Point of Trust A requests the identi¬cation
of client A.2 to communicate.
Client A.2 receives the request and sends his data (authenticity, authorization,
accounting information, etc.) to Point of Trust A as response in order to be iden-
ti¬ed as part of Trust Zone A. Point of Trust A receives the response and checks
the data of client A.2. After positive validation, the information relevant to the com-
munication is sent to client A.2, introducing the requesting communication party,
client A.1.
Client A.2 con¬rms the request for communication from client A.1 and takes
initiative.



Step 2: Setup of secure communication
The communication steps to setup secure communication are delineated subse-
quently.
Client A.1 and Point of Trust A are ready to communicate and generate Stream 1,
a shared stream generated by using quantum mechanical techniques, over a quantum
channel. Analog, Stream 2 is generated between Point of Trust A and client A.2
which is ready to communicate too.
Both communication parties have generated streams they share with Points of
Trust A. Point of Trust A encrypts Stream 2 using Stream 1 to generate Stream 3.
Stream 3 is then transmitted to client A.1.
Client A.1 receives Stream 3 and uses Stream 1, which is known to him, to
reproduce Stream 2. Stream 2 is subsequently established as the session key for
the communication parties, client A.1 and client A.2.



10.4 Exempli¬ed Communications
The following section presents examples of communication models. It shows the
difference between the setups for communications between several Trust Zones and
within one Trust Zone and the setup for the generation of the bit stream itself.
10 The Ring of Trust Model 195

10.4.1 Communication Between Several Trust Zones
In this system two Points of Trust are involved which are either connected directly
or over an arbitrary network structure.


10.4.1.1 Initiation of Communication
At the beginning of the communication, it must be determined whether it is in the
interest of the network operator and the two communication parties to set up com-
munication. The request for communication is set up by preparing the required data
in a packet.
The content of such a packet could be exempli¬ed by the following:

• Initiator: The identi¬cation of the initiator, in this example the identi¬cation of
client A.1, by a unique network address, which can be compared with other net-
work protocols like IP.
• Target: Identi¬cation of the party who is requested to communicate, in this case
the identi¬cation of client B.2.
• Time when communication is initiated: Determines the desired time of commu-
nication. Additionally, a token for an immediate setup of communication could
be de¬ned.
• Conditions for the setup of communication: Permits the de¬nition of tokens
regarding different communication factors. Examples of such tokens are payment
(by initiator, target, other accounts, e.g., of a company), responsibility for the
transmitted data, priority of communication, level of secrecy.

This request is transmitted over a public channel to the responsible Point of Trust,
in this example Point of Trust A. In the ¬rst step the data of the initiator is examined.
Such a check could include information as to, e.g., the authenticity, the authorization
of the initiator to communicate (with the target, the level of secrecy, the point in
time, etc.), and accounting information. If the validation fails, the communication is
terminated and a response is generated accordingly.
If the identi¬cation is valid, then the information relating to the target is checked.
The information check could include factors like availability of the target, level of
secrecy of the communication. If the check yields a negative result, the communi-
cation is terminated and an appropriate message is transmitted to the initiator.
If the check yields a positive result, the request is forwarded to the Point of Trust,
which is responsible for the target. This Point of Trust can be contacted in different
ways. Examples are a hierarchical organization of the different Points of Trust or a
direct connection of all Points of Trust.
The target™s Point of Trust receives and processes the request. At this point, the
data of the target is checked. Now the accounting information of the target could be
checked, as this information may only be known to the respective client. Information
regarding the level of secrecy or the ring of authorized communication parties could
only be known to the responsible Point of Trust and might also be checked at this
196 C. Kollmitzer and C. Moesslacher

stage. If the check yields a negative result, the communication is terminated and an
appropriate message is sent.
Additionally, the responsible Point of Trust could request the authentication of
the target. At the same time, the target would be informed about the request for
communication. Now all the information of the request can be transmitted. Alter-
natively, the data related to the request is forwarded after the positive identi¬cation,
as depicted in Fig. 10.9. In this example the data required for communication is
transmitted only after a valid identi¬cation of the target. This guarantees a higher
level of security.
If the identi¬cation of the target fails, then the setup of communication is termi-
nated and a response is sent accordingly. Otherwise the request is forwarded to the
target. The target then decides whether to accept or reject the setup of communica-
tion. The response of the target is then routed to the initiator and to all Points of Trust
involved. Depending on the form of communication the participants had previously
agreed on (level of secrecy, accounting information, etc.) and the determined time,
the required initializations can now be prepared.
In the case of a negative response, e.g., caused by the termination of commu-
nication, the initiator can start a new setup of communication. The Point of Trust
may employ mechanisms to make use of operation parameters like, e.g., maximal
number of attempts to set up communication over a certain period of time, costs per
communication attempt.
Note: A higher level of security could be obtained by encrypting all the com-
munication between the respective parties. Symmetric ciphers like block ciphers,
stream ciphers, or asymmetric systems based on a central PKI would be suitable for
that purpose.



10.4.1.2 Setup of Secure Communication
Once the communication is initiated the next step is to generate the required streams
and to set up a secure communication as seen in Figs. 10.9 and 10.10. The initiator of
the communication generates a stream with speci¬ed quality criteria and a respective
key length with its Point of Trust. A key length of 256 bits is agreed upon to work
subsequently with an encryption of, e.g., AES (see [2]).
As a next step the generated status is checked. A negative status leads to the
termination of the communication. If the generation status is positive, the generated
stream is encrypted by the initiator™s Point of Trust. Symmetric ciphers like AES or
asymmetric systems like PKIs can be used to encrypt the stream.
After receiving the encrypted Stream 1, the target™s Point of Trust initiates the
generation of a stream (Stream 2) with the target. Again different quality criteria can
be agreed on. Depending on the encryption algorithm, that is subsequently used, the
Stream 1 and Stream 2 have to be of equal length. Then the status is checked. In
case of a negative status the communication is terminated.
If the status proves positive, then the encrypted Stream 1 is decrypted. As a next
step Stream 1 is encrypted by Stream 2 to produce Stream 3. A One-Time-Pad cipher
10 The Ring of Trust Model 197




Fig. 10.9 Request for communication setup
198 C. Kollmitzer and C. Moesslacher




Fig. 10.10 Setup of secure communication
10 The Ring of Trust Model 199

using the two streams is an example of a possible encryption. In this case, it is
necessary that the streams are of equal length and ful¬l prede¬ned quality criteria.
Stream 3, which has been generated in this manner, is then transmitted to the
target. The target decrypts Stream 3 using Stream 2. The result of the decryption
(Stream 1) is subsequently referred to as the Session key.
The target now sets up communication with the initiator. Algorithms like AES
or IDEA could be employed. Next, the setup of communication is checked. If the
communication check yields a negative result, then the communication is termi-
nated. If the result is positive, the communication is secure in the framework of the
method.
Note: After the communication has been terminated, an appropriate message is
sent to all of the participating communication parties. It is up to the system operator
to de¬ne further steps in the event of the termination of a communication and to,
e.g., repeat failed attempts. Whether a repeated attempt is permissible could depend
on the requirements de¬ned in the ¬rst step of the communication setup or on the
prearranged time.



10.4.2 Communication in One Trust Zone
10.4.2.1 Initiation of Communication
At the beginning of the communication, it must be determined whether it is in the
interest of the network operator and the two communication parties to set up com-
munication. The request for communication is set up by preparing the required data
in a packet.
The content of such a packet could be exempli¬ed by the following:

• Initiator: The identi¬cation of the initiator, in this example the identi¬cation of
client A.1, by a unique network address, which can be compared with other net-
work protocols like IP.
• Target: Identi¬cation of the party who is requested to communicate, in this case
the identi¬cation of client A.2.
• Time when communication is initiated: Determines the desired time of commu-
nication. Additionally a token for an immediate setup of communication could
be de¬ned.
• Conditions for the setup of communication: Permits the de¬nition of tokens
regarding different communication factors. Examples of such tokens are payment
(by initiator, target, other accounts, e.g., of a company), responsibility for the
transmitted data, priority of communication, level of secrecy.

This request is transmitted over a public channel to the responsible Point of Trust,
in this example Point of Trust A. In the ¬rst step the data of the initiator is examined.
Such a check could include information as to, e.g., the authentication of the initiator,
authorization of the initiator to communicate (with target, the level of secrecy, the
200 C. Kollmitzer and C. Moesslacher

point in time, etc.), and accounting information. If the validation fails, the commu-
nication is terminated and an appropriate response is generated.
If the check yields a positive result, the information related to the target is exam-
ined. The check could include factors like, e.g., availability of the target, authoriza-
tion to communicate with the initiator, accounting information of the target, level of
secrecy. If the check yields a negative result, the communication is terminated and
an appropriate message is forwarded to the initiator.
Additionally, the Point of Trust could request the identi¬cation of the target. At
the same time, the target would be informed about the request for communication.
Now all the information of the request can be transmitted. Alternatively, the data
related to the request is forwarded after the positive identi¬cation, as depicted in
Fig. 10.11. In this example the data required for communication is transmitted only
after a valid identi¬cation of the target. This guarantees a higher level of security. If
the identi¬cation fails, then the setup of communication is terminated and a response
is sent accordingly.
Otherwise the request is forwarded to the target. The target then decides whether
to accept or reject the setup of communication. The response of the target is then
routed to the initiator and to the Point of Trust. Depending on the form of com-
munication the participants had previously agreed on (level of secrecy, accounting
information, etc.) and the determined time, the required initializations can now be
prepared.
In the case of a negative response, e.g., caused by the termination of commu-
nication, the initiator can start a new setup of communication. The Point of Trust
may employ mechanisms to make use of operation parameters like, e.g., maximal
number of attempts to set up communication over a certain period of time, costs per
communication attempt.
Note: A higher level of security could be obtained by encrypting all the commu-
nication between the respective parties. Symmetric ciphers like block ciphers (AES,
IDEA, etc.), stream ciphers (one-time-pad, SEAL 2.0, etc.), or asymmetric systems
based on a central PKI would be suitable for that purpose.


10.4.2.2 Setup of Secure Communication
Once the communication is initiated the next step is to generate the required streams
and to set up a secure communication as shown in Figs. 10.11 and 10.12. The ini-
tiator of the communication generates a stream with speci¬ed quality criteria and a
respective key length with his Point of Trust. For example, a key length of 256 bits
is needed to work subsequently with AES (see [2]).
As a next step the status of the generation is checked. A negative status leads
to the termination of the communication. If the status of the generation is positive,
then the Point of Trust initiates the generation of a stream (Stream 2) with the target.
Again, certain quality criteria (like [1]) can be agreed on. Depending on the encryp-
tion algorithm that is subsequently used, Stream 1 and Stream 2 have to be of equal
length. Then the status is checked. In case of a negative status the communication
is terminated. If the status proves positive, Stream 1 is encrypted by Stream 2 to
10 The Ring of Trust Model 201




Fig. 10.11 Request for communication setup
202 C. Kollmitzer and C. Moesslacher




Fig. 10.12 Setup of secure communication
10 The Ring of Trust Model 203

produce Stream 3. A One-Time-Pad cipher using the two streams is an example of a
possible encryption. In this case, it is necessary that the streams are of equal length
and ful¬l prede¬ned quality criteria.
Stream 3, which has been generated in this manner, is then transmitted to the
target. The target decrypts Stream 3 by using Stream 2. The result of the decryption
(Stream 1) is subsequently referred to as the Session key.
The target now sets up communication with the initiator. Algorithms like AES
or IDEA could be employed. Next, the setup of communication is checked. If the
communication check yields a negative result, then the communication is termi-
nated. If the result is positive, the communication is secure in the framework of the
method.
Note: After the communication has been terminated, an appropriate message is
sent to all of the participating communication parties. It is up to the system operator
to de¬ne further steps in the event of the termination of a communication and to,
e.g., repeat failed attempts. Whether a repeated attempt is permissible could depend
on the requirements de¬ned in the ¬rst step of the communication setup or on the
prearranged time.



10.4.3 Generation of a Stream

At the beginning of the generation process, the initiator prepares a detailed request
as seen in Fig. 10.13. This request could include different tokens like the length of
the stream that is to be generated, the quality criteria of the stream, e.g., FIPS 140-2
[1], criteria according to Golomb [9], linear complexity [9].
The request is forwarded to both communication parties and serves to initiate
respective steps such as the preparation of the system (adjustments, self test, etc.),
logging.
The participating communication parties generate a stream using a respective
protocol, e.g., BB84 [3].
Once a stream with the speci¬ed length is generated, it is checked by one of the
communication parties involved. In this check, the quality criteria speci¬ed in the
request can be checked. If the test leads to the rejection of the generated stream,
an appropriate error message is generated and sent to the second communication
party.
If the stream is approved, a positive status message is generated. This message
con¬rms that both communication parties now share a key, which has been gener-
ated by both parties.
It could be up to the initiator to make another attempt at generating a key if one
try results in an error message. In this case, the system operator could interfere by,
e.g., limiting the number of attempts over a certain period of time, charging each
attempt separately.
If the attempt is not repeated, a negative status message is generated. It con¬rms
that no shared key could be generated.
204 C. Kollmitzer and C. Moesslacher




Fig. 10.13 Generation of a stream



10.5 A Medical Information System Based on the Ring of Trust

10.5.1 Field of Research
10.5.1.1 Availability on Demand
Besides the distribution of high-quality keys in an adequate amount also the storage
of these keys is very important. In large data-processing centers it is possible to
securely store such sensitive data since the required environment (access control,
backup structure, hardware architecture) is present. But most of the commercial and
private users do not have this kind of environment at their disposal. Thus we can
state the requirement: keys should be generated on demand and not on supply to
overcome the problems of their secure storage.


10.5.1.2 Scalability
Today we have different requirements about the security level of transmitted data.
The data which gets transmitted during an online surgery over the Internet needs a
10 The Ring of Trust Model 205

much higher security level than most other data. Therefore it is necessary to draw a
distinction between certain security levels for data to optimize speed and reduce the
amount of needed resources.
Within a medical information system there exists data which could be encrypted
with a classical algorithm for an adequate security level. There also exists data
that is subject to legal requirements and hence needs to be encrypted with a cer-
tain algorithm. Further kinds of data need to be encrypted with prede¬ned security
algorithms to allow the use within existing environments or already used protocols
like VPN. But beside this, most companies today have to maintain huge databases
and transmit huge amounts of highly critical data, which needs high-level security.


10.5.1.3 The Problems of Distance and Speed
In our opinion it is another basic aspect that keys of adequate quality need to be
available over long distances and with the according quality. QKD provides high-
quality keys but today it is not possible to generate keys over very long distances.
Within QKD systems increasing distance between Alice and Bob leads to decreasing
transmission speed. So the deployment of classical QKD-based networks is limited.


10.5.2 Requirements
Medical Information Systems (MIS) [6, 8, 11] consisting of data-processing units
like Radiology Information System (RIS), Lab Information System (LIS) [8], Dig-
ital Imaging and Communications in Medicine (DICOM), Health Level 7 (HL7)
[10, 5], Picture Archiving and Communicating System (PACS) [6], ORBIS (MIS
powered by GWI AG), International Statistical Classi¬cation of Diseases and Related
Health Problems (ICD-10) [8] database or any other kind of digital information
system are essential components of modern medical data processing units.
It is commonly known that patient-related data is highly sensitive. This kind
of data needs to be stored for a longtime and its privacy has to be guaranteed for
the whole time of storage. Only to a selected group of people like doctors or the
nursing staff the access to the patient-related data should be granted. To prevent
an intervention of an adversary it is essential to encrypt patient-related data during
the transmission. Here it does not matter whether this information contains recipes,
radiology reports, or any other kind of medical data.
Telemedicine is part of telematics-related surgeries [7] where a surgeon operates
on a patient over a long distance “ maybe even in another country. The surgeon™s
physiological transaction data is transmitted, for example, from Vienna to the oper-
ating theatre in Klagenfurt over a public channel. This highly sensitive data (e.g.,
heart surgeries over the Internet via triggering ”da Vinci” surgery robot) needs to
be protected against any adversary. Other important aspects besides high level of
security are transmission speed and independence of the amount of transmitted data.
Manipulation of data is a severe threat and especially in medicine it could result
in devastating consequences. Thus it is necessary to implement modern crypto-
graphic methods into existing infrastructures. Additionally, techniques are needed
206 C. Kollmitzer and C. Moesslacher

which are easy to implement and also provide a high level of security and ful¬l the
requirements for transmission speed and long-range communication.


10.5.2.1 Results of the Survey
The survey [4] shows that the participants (medical technicians, commercial service
providers, exc.) are very well informed about the state-of-the-art Medical Informa-
tion Systems (cf. Fig. 10.14).




90

80

70

60

50
%
40

30

20

10

0
Yes No Unknown

Fig. 10.14 Awareness about state-of-the-art Medical Information Systems



Regarding the privacy of transmitted data about 40% agreed that more than 75%
of the communication has to be encrypted. Almost two-thirds say that more than
50% of the transmitted and stored data is sensitive (cf. Fig. 10.15).
As a result of the survey about 90% of the participants agreed that in medical data
processing the need for high-quality security solutions is given. About 60% of the
participants stress that current architectures could not meet the requirements stated
in Sects. 10.5.1.1, 10.5.1.2, 10.5.1.3. They stated that modern solutions are needed
to protect the patient™s privacy to reach a high level of security (cf. Fig. 10.16).
QKD is a solution to these problems. It provides high-quality keys and ful¬ls
the requirements from Sects. 10.5.1.1 and 10.5.1.2. A drawback of quantum key
distribution is the range in which it is operable since it is rather low (about 20 km).
But certain models like the Ring of Trust are able to solve also these problems.
10 The Ring of Trust Model 207


45

40

35

30

25
%
20

15

10

5

0
Zero




Less than 25%




Less than 50%




Less than 75%




More than 75%
Fig. 10.15 The amount of sensitive data in Medical Information Systems




70

60

50

40
%
30

20

10

0
Very High Very High Little Unimportant
(existing (existing
solutions solutions not
sufficient) sufficient)

Fig. 10.16 The need for high-level security in Medical Information Systems
208 C. Kollmitzer and C. Moesslacher

10.5.3 Enhanced Ring of Trust model
We can see that there is high demand within medical information systems, not only
on generating shared secrets for communication but also to store information in a
high secure way. It is absolutely necessary to get access to this highly protected
information from any place at any time but only under certain circumstance. To
enable this we present an enhanced Ring of Trust model with a special client by
introducing a storage client as shown in Figs. 10.17 and 10.18.


10.5.3.1 Storage Client at a Foreign Point of Trust
To access the information on the storage client of a foreign Point of Trust a client
A.1 has to take the following steps:

1. Client A.1 generates a key K A with his Point of Trust. Client A.1 is a member of
Trust Zone A and therefore assigned to Point of Trust A.
2. The key K A is transmitted on a secure channel to the Point of Trust where the
storage client is located, the Point of Trust B.
3. Point of Trust B generates key K B with the storage client, encodes K A with K B
to K C (for example, by using the XOR operation) and sends this key either using
the secure environment of Point of Trust B if the storage client is located within
this secure environment or using a public channel.



Public channel; Secure Environment PoT B
Other points of trust




Point of Trust A Point of Trust B Storage Client


Quantum channels Quantum channels


Trust Zone A Trust Zone B




Client A.1 Client A.2 Client A.n Client B.1 Client B.2 Client B.m




Public channel




Fig. 10.17 Enhanced ring of trust model with storage client at a foreign point of trust
10 The Ring of Trust Model 209

Fig. 10.18 Enhanced ring of Secure Environment PoT
trust model with storage
client at the home point of
trust



Point of Trust Storage Client


Quantum channels


Trust Zone




Client 1 Client 2 Client n




4. As the storage client knows K B he is able to obtain K A from K C by calculating
K A = KC • K B .
With K A the storage client is now able to establish a secure connection to client
A.1. If the storage client is located within the secure environment of the Point of
Trust, it would be possible to transmit K A directly to the storage client without the
generation of K B .


10.5.3.2 Storage Client at the Home Point of Trust
To get access to the information on the storage client at the same trust center, a client
has to take the following steps:
1. Client A.1 generates a key K A with his Point of Trust. Client A.1 is a member of
Trust Zone A and therefore assigned to Point of Trust A.
2. If the storage client is located within the secure environment of Point of Trust A,
key K A could be transmitted directly to the storage client.
3. If the storage client is not located within the secure environment but within the
Trust Zone of Point of Trust A a key K B can be generated by the Point of Trust
and the storage client.
4. The Point of Trust encodes a new key K C by calculating K C = K A • K B and
sends this key to the storage client by using a public channel.
5. As the storage client knows K B he is able to calculate K A from K C .
Using K A the storage client is now able to establish a secure connection to client
A.1.
210 C. Kollmitzer and C. Moesslacher

References
1. F.I.P.S.P. Security Requirements for Cryptographic Modules. NIST, 140-2 200, 203
2. F.I.P.S.P, 197: Announcing the Advanced Encryption Standard (AES). NIST 196, 200
3. Bennet, C.H., Besset, F., Brassard, G., Salvail, L., Smolin, J.: Experimental Quantum Crypto-
graphy. J. Cryptology 5, 3(1992) 203
4. Dissauer, G.: Security requirements of modern medical information systems. Master™s thesis,
Vienna University of Technology, Austria (2007) 206
5. Dolin, R.H., Aschuler, L., Boyer, S., Beebe, C., Behlen, F.M., Biron, P.V., Shabo, A.: Medical
Informatics Europe. J. Am. Med. Inform Assoc. (2006) 205
6. Haas, P.: Medizinische Informationssysteme und elektronische Krankenakten. Springer
Verlag, Berlin, Germany (2004) 205
7. Iakovidis, I.: Towards a Health Telematics Infrastructure in the European Union. European
Commission, Brussels, Belgium (2000) 205
8. Lehmann, T.M.: Handbuch der Medizinischen Informatik. Carl Hanser Verlag, Munchen,
Germany (2005) 205
9. Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC
Press Boca Raton (1996) 203
10. Smith, B., Ceustersc, W.: Medical Informatics Europe. Maastricht, Netherlands (2006) 205
11. van Bemmel, J., Musen, M.A.: Handbook pf Medical Informatics. Springer Verlag,
Heidelberg, Germany (1997) 205
Index




A Collective attacks, 71
ACKNOWLEDGE keyword, 165 Collision probability, 72
AES, 177 Common Store, 163
Akaike Information Criterion, 142 Conditions, 195, 199
Alice™s imaginary result, 87 Conical mirror, 113
AlInGaP LED, 115 Continuous Variables, 106
All-or-nothing principle, 159 Controlled NOT, 80
Application KeyStore, 181 Cook statistics, 142
ARC, 118 COW, 103
Authentication, 16 Cox process, 56
Authentication check, 162 Cramer“von Mises two sample test, 128, 134,
Authentication cost, 30 138, 139
Authentication of Error Correction, 39 Crypto Contexts, 157
Availability on Demand, 204 Crypto Engine, 156
CV protocols, 106
B
Backscattering light, 99
D
Bayesian estimation, 55
Dark counts, 89
BB84-Like Protocols, 79
Decoy pulses, 101
Beam splitter, 25
Bell state measurement, 84, 86 Decoy sequences, 104
Best linear unbiased estimator, 67 Delayed Authentication, 160
Best unbiased estimator, 67 Designated Keys, 182
BINARY, 36 Designs of experiments, 68
Bit ¬‚ip, 6 Detector, 25
Bit separation, 104 Dispersion parameter, 124
Bloch sphere, 4 Doubly stochastic Poisson processes, 62
Breidbart basis, 75, 77 Driver circuit, 115
Dynamic Initial Block-Size, 56
C
Cabello, 84, 86, 88
E
Canonical parameter, 124
Eavesdropper, 26
Cascade, 36, 50, 116
Encapsulation, 154
Channels, 156
Entanglement-Based QKD, 109
CNOT, 80
Entropy, 19
CNRS-Institute d™Optique-Univ. Paris-Sud,
Error Detection and Correction, 152
118
Error estimation, 31
Coherent attacks, 71
Extended Routing Table, 168
Coherent one-way QKD system, 103



Kollmitzer, C., Pivk, M. (eds.): Index. Lect. Notes Phys. 797, 211“214 (2010)
c Springer-Verlag Berlin Heidelberg 2010
DOI 10.1007/978-3-642-04831-9
212 Index

F L
Laplace method, 126
Faked States Attack, 92
Least-squares ¬tting, 56
Finite resources, 46
Li, 86
Fixed Initial Block-Size, 53
Light injection attack, 91
Fock states, 90
Link Control Protocol (LCP), 154
Free Keys, 182
Load State Database, 168
Free-Space QKD, 112
LOAD subprotocol, 165
Full detector ef¬ciency mismatch, 92
Low-Cost QKD, 114
Low-density Parity Check, 117
G LSA, 167
GAP, 103
GAP-Universit´ de Gen` ve, 118
e e M
Generalized linear mixed model, 123, Mach“Zehnder phase encoding interferometer,
126, 145 102
Generalized linear models (GLMs), 123 Man-in-the-middle attack, 14
Generation of a Stream, 203 Markov networks, 64
GHZ state, 84 Matrix representation, 5
GLM, 124 Maximum likelihood estimator, 53
Measurement operators, 10
GLMM, 123, 126, 145
Medical information systems (MIS), 185
Global phase factor, 4
Message-Based Streaming, 157
Group of Applied Physics, University of
Micro SD memory cards, 176
Geneva, 103
Monitoring line, 104
Monte Carlo methods, 56, 127
H Multi-photon components, 111
Hadamard operation, 83
Hierarchical model, 187 N
Hilbert space, 3 NCP, 154
Holevo quantity, 108 Near Field Communication, 177, 178
Homodyne detection, 107 Network Control Protocol, 154
Hop-by-hop basis, 153 NFC, 177, 178
No-cloning theorem, 13
Nodes, 152
I
NuDAQ, 115
IdQuantique SA, 117, 118
Individual attacks, 71
O
Information leaking, 50
One-time-pad (OTP), 152, 176
Initiator, 195, 199
One-way decoy pulse QKD system, 100
In-KeyStore, 181 Optical Transmission, 179
Inner product, 7 OSPF, 168
Instant Authentication, 160 Out-KeyStore, 181

<<

. 8
( 9)



>>