Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
114 Military Communications and Information Technology... In the example the SubCA mission-A is derived from the central SubCAmission-A and, therefore, inherits its trust relationships. This means that the central SubCA-mission-A has a trust relationship with the central SubCA-mission-B in the example above. Further deployable and autonomous IT systems may exist in the theater of operations. These systems derived from the central SubCA-mission contain a separate SubCA. These SubCAs form the deployable SubCA mission of layer 4. Depending on the requirements of the theater of operations, mobile and autonomous IT systems (SubSubCAs) are distributed from the deployable SubCA mission and, if applicable, also from the central SubCA-mission. These IT systems (may) contain separate limited mobile SubCAs (layer 5). The establishment of trust relationships may be required independent of the CA layer. The example in Figure 4 illustrates the establishment of a trust relationship to a Greek SubCA in the mobile SubCA operation-1b. CA* and/or SubCA* are introduced due to the fact that technical domains are autonomous but not every technical domain of layer 5 automatically needs to have its own CA* or SubCA*. Like a CA or SubCA, the CA* and/or SubCA* receives a share of information from its respective higher-level CA. This CA* or SubCA* does, however, not form a CA or SubCA in organizational terms, but it remains assigned to its issuing CA or SubCA. Synchronizations used to compare changes in the trust relationship and in the revocation list are required due to the CA structure and the direct trust relationship. Figure 5 illustrates the synchronization relationships resulting from the CA structure and the direct trust relationships in the example in Figure 4. Figure 5. CA structure & trust synchronization relationships Details of the procedures to create and maintain the various certificates in RuDi are described in [18], chapter 3.
Chapter 2: Communications and Information Technology for Trusted... 115 SOA runtime security The SOA Runtime Security is concerned with all steps and capabilities of IT security during service use and comprises: • Authentication (checking the identity – identification); • Authorization (check of authorization – access authorization); • Encryption (digital encryption); • Signature (electronic signature/ identification). The definition of “addressing and identification” forms the basis of the SOA Runtime Security. For all considerations concerning IT security it has to be noted that the IT security mechanism is regarded across technical domains (see Figure 6). It must be ensured that the mechanism is the same, both domain-internally and externally, and that simplifications working only domain-internally are not being established too quickly. Figure 6. Federation and trust configuration This means that the transmitter and receiver instance may be located in different technical domains, each with its own SOA (ESB) infrastructure. IV. Conclusion While web services have come a long way in ensuring interoperability, the profiles written for use in civil systems are insufficient for use in tactical military networks. We have in this article introduced the areas which have been identified in CoNSIS as the areas in which further specifications are necessary. Solutions for these areas have been developed in the German national project Reference Environment for Services RuDi and are being verified in various field tests including
- Page 63 and 64: Chapter 1: Concepts and Solutions f
- Page 65 and 66: Chapter 1: Concepts and Solutions f
- Page 67 and 68: Chapter 1: Concepts and Solutions f
- Page 69 and 70: Chapter 1: Concepts and Solutions f
- Page 71 and 72: Selected Aspects of Effective RCIED
- Page 73 and 74: Chapter 1: Concepts and Solutions f
- Page 75 and 76: Chapter 1: Concepts and Solutions f
- Page 77 and 78: Chapter 1: Concepts and Solutions f
- Page 79 and 80: Chapter 1: Concepts and Solutions f
- Page 81: Chapter 1: Concepts and Solutions f
- Page 84 and 85: 84 Military Communications and Info
- Page 86 and 87: 86 Military Communications and Info
- Page 88 and 89: 88 Military Communications and Info
- Page 90 and 91: 90 Military Communications and Info
- Page 92 and 93: 92 Military Communications and Info
- Page 94 and 95: 94 Military Communications and Info
- Page 96 and 97: 96 Military Communications and Info
- Page 98 and 99: 98 Military Communications and Info
- Page 100 and 101: 100 Military Communications and Inf
- Page 103: Chapter 2 Communications and Inform
- Page 106 and 107: 106 Military Communications and Inf
- Page 108 and 109: 108 Military Communications and Inf
- Page 110 and 111: 110 Military Communications and Inf
- Page 112 and 113: 112 Military Communications and Inf
- Page 116 and 117: 116 Military Communications and Inf
- Page 118 and 119: 118 Military Communications and Inf
- Page 120 and 121: 120 Military Communications and Inf
- Page 122 and 123: 122 Military Communications and Inf
- Page 124 and 125: 124 Military Communications and Inf
- Page 126 and 127: 126 Military Communications and Inf
- Page 128 and 129: 128 Military Communications and Inf
- Page 130 and 131: 130 Military Communications and Inf
- Page 132 and 133: 132 Military Communications and Inf
- Page 134 and 135: 134 Military Communications and Inf
- Page 136 and 137: 136 Military Communications and Inf
- Page 138 and 139: 138 Military Communications and Inf
- Page 140 and 141: 140 Military Communications and Inf
- Page 142 and 143: 142 Military Communications and Inf
- Page 144 and 145: 144 Military Communications and Inf
- Page 146 and 147: 146 Military Communications and Inf
- Page 149 and 150: Use of Cross Domain Guards for CoNS
- Page 151 and 152: Chapter 2: Communications and Infor
- Page 153 and 154: Chapter 2: Communications and Infor
- Page 155 and 156: Chapter 2: Communications and Infor
- Page 157 and 158: Chapter 2: Communications and Infor
- Page 159: Chapter 2: Communications and Infor
- Page 162 and 163: 162 Military Communications and Inf
114 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />
In the example the SubCA mission-A is derived from the central SubCAmission-A<br />
<strong>and</strong>, therefore, inherits its trust relationships. This means that the central<br />
SubCA-mission-A has a trust relationship with the central SubCA-mission-B<br />
in the example above.<br />
Further deployable <strong>and</strong> autonomous IT systems may exist in the theater of operations.<br />
These systems derived from the central SubCA-mission contain a separate<br />
SubCA. These SubCAs form the deployable SubCA mission of layer 4.<br />
Depending on the requirements of the theater of operations, mobile <strong>and</strong><br />
autonomous IT systems (SubSubCAs) are distributed from the deployable SubCA<br />
mission <strong>and</strong>, if applicable, also from the central SubCA-mission. These IT systems<br />
(may) contain separate limited mobile SubCAs (layer 5).<br />
The establishment of trust relationships may be required independent of the CA<br />
layer. The example in Figure 4 illustrates the establishment of a trust relationship<br />
to a Greek SubCA in the mobile SubCA operation-1b.<br />
CA* <strong>and</strong>/or SubCA* are introduced due to the fact that technical domains are<br />
autonomous but not every technical domain of layer 5 automatically needs to have<br />
its own CA* or SubCA*. Like a CA or SubCA, the CA* <strong>and</strong>/or SubCA* receives<br />
a share of information from its respective higher-level CA. This CA* or SubCA*<br />
does, however, not form a CA or SubCA in organizational terms, but it remains<br />
assigned to its issuing CA or SubCA.<br />
Synchronizations used to compare changes in the trust relationship <strong>and</strong><br />
in the revocation list are required due to the CA structure <strong>and</strong> the direct trust<br />
relationship. Figure 5 illustrates the synchronization relationships resulting from<br />
the CA structure <strong>and</strong> the direct trust relationships in the example in Figure 4.<br />
Figure 5. CA structure & trust synchronization relationships<br />
Details of the procedures to create <strong>and</strong> maintain the various certificates in RuDi<br />
are described in [18], chapter 3.