Testbed-12 Aviation Security Engineering Report

This Engineering Report (ER) gives guidelines for security architecture implementation with OGC OWS compatible web services especially for the domain of civil aviation and based on the Testbed-12 aviation architecture. The document is applicable to all readers interested in the aviation domain and the common information security topics related to the OGC web services.

All questions regarding this document should be directed to the editor or the contributors:

No future work is planned to this document.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Most diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 06-121r9].

In SESAR, System Wide Information Management (SWIM) has been specified at the technical (endpoints, solution stacks) and at the service (logical interfaces) level. At the technical level there are three so called profiles with different requirements which also affects security. Every profile contains many stack definitions. Following listing gives an overview into the one of them, the web technology (and thus relevant for OGC OWS) based Yellow Profile technical specification. Here we provide an incomplete list of generic interface binding titles. They are descriptive enough to explain what kind of communication stack and security is required:

Following given an detailed overview into a generic interface binding with support for WS-* standard stack:

SOAP 1.2 with WS-Security 1.1, WS-Trust 1.4, WS-Federation 1.2, and WSSE X.509 Certificate Token Profile 1.1 and/or WSSE SAML Token Profile 1.1 over HTTP POST over TCP.

Generic service instantiation shall be supported on the following interface binding:

Access management refers to the process of controlling and granting access to satisfy resource requests. This process is usually completed through a sequence of authentication, authorization, and auditing actions. Authentication is the process by which identity claims are proven. Authorization is the determination of whether an identity is allowed to perform an action or access a resource. Auditing is the accounting process for recording security events that have taken place. Together, authentication, authorization, and auditing are also commonly known as the “gold standards of security”.

In the Access Control mechanism for Request/Reply service consumption scenario expected in SWIM, a Service Consumer shall prove its identity in order to invoke a service provided by a Service Provider. At the same time, a Service Provider shall prove its identity in case mutual authentication is required. Such Access Control mechanism is realized through combination of Identity Management, Authentication and Authorization Functions. SWIM-TI Authentication Function aims at authenticating Digital Identity: this mainly consists of verifying that a claimed identity of an entity is legitimate by evaluating additional information (authentication credentials) that is bound to this identity and can only be provided by an entity with that identity.

In the Access Control mechanism for service consumption scenario expected in SWIM, an (ATM SWIM Enabled) Service Consumer, whose identity has been proved previously by Authentication Function, shall be authorized in order to consume a service provided by an (ATM SWIM Enabled) Service Provider.

The authorization decision making process is based on two key inputs:

Authorization function relies on Authentication Function (identity authentication), Identity Management Function (for security attributes assigned to that identity), on Security Policy Enforcement (PE) and Security Policy Management.

The relationship between Authorization Function and Policy Enforcement Function consists of the fact that the authorization policy is enforced by the PE which relies on the authorization function as Policy Decision Point for Authorization Policies. For what concerns the Security Policy Management, the link consists of the fact that an authorization policy can be used across security domains only if there is a proper cross security domain policies lifecycle management. It is worth noting that there is a difference between authentication and authorization policies: a policy on the level of authentication required and how to achieve it, is called an authentication policy; deciding whether a given authentication level is sufficient for access is an authorization policy.

Confidentiality function is the process by which sensitive information is only accessible by granted (“right”) users. It ensures non-disclosure of information to users that do not own a given secret. This function relies on the policy enforcement and management features and it is based on cryptographic mechanisms.

Confidentiality function covers both data encryption and data decryption) and data in transit (e.g. OGC aviation services invoked by a service consumer). Data encryption is performed on service consumer side at service-request sending and by service provider side at service-response sending. Data decryption is performed by service provider side at request reception and by service consumer side at response reception. In order to interoperate service consumer and provider shall agree on cryptographic mechanisms they will use. Cryptographic mechanisms include algorithms, encryption granularity and key validity. The agreement can be dynamically negotiated at connection time or statically configured in a dedicated policy. The fact that a single Confidentiality Policy is deployed on both service consumer and service provider ensures interoperability.

The link between the Confidentiality function and the PEP consists of the fact that "data" specific confidentiality security policies are enforced by the PEP which relies on the confidentiality service as PDP for that kind of policy. This kind of policy specifies, for a given data, assertions such as if confidentiality required or not, which key schema has to be applied (symmetric/asymmetric), which encryption algorithm has to be used, which parts of the messages have to be encrypted, etc. Thanks to the combination of these policies and the cryptographic enabler it is possible to support simple and very complex confidentiality requirements.

Cryptographic algorithm can be symmetric or asymmetric. Symmetric-key algorithm uses the same cryptographic key for both encryption and decryption. A simple transformation (that could even be identity) allows getting decryption key from encryption key. The key pair is the shared secret between the two parties. Asymmetric-key algorithm requires two separate keys. One of which is private, the other is public. The private key is kept secret by the owner and is never sent in a message. The public key is used for encryption and the private key is used for decryption. The public key shall be known by any confidentiality function requiring encrypting data. The management (creation, deployment and revocation of pairs of public/private keys) is handled by a Public Key Infrastructure (PKI).

Confidentiality function can be addressed none exclusively at network level, transport level or message level.

Data Origin Authentication function is the process ensuring data in transit is not altered (data integrity) and that they originate from the expected sender (authenticity). Data Origin Authentication also addresses Non-Repudiation because digital signature can provide evidence that an actor has performed some operations related to data, though the degree to which an entity can be held accountable shall be established in an agreement between parties.

Data origin authentication covers both data signing at the origin and data-signature verification at the destination. It does not cover data validity that is a mechanism ensuring the data correctness in the actual context of usage. This function is based on cryptographic mechanisms enabling digital signature.

Data Origin Authentication can be realized using a combination of either symmetric or asymmetric signature and hashing techniques. Symmetric signatures is performed by using a shared secret to sign and verify the message, producing what is called a Message Authentication Code (MAC) that consists of a checksum of the original message that is encrypted using the shared key.

Asymmetric Signature is performed with a scheme involving a pair of public and private keys. One of which is used to create the signature and the other is used to verify the signature. The private key is kept secret by the owner and is never sent in a message, while he public key is generally available and can be distributed with the message but its authenticity (i.e. association between the public key and the carrying entity) shall be guaranteed by a PKI using a digital certificate allowing a message recipient to verify the private key in a client’s signature using the public key in the client’s certificate. Since the private key is restricted to the owner of the key, the signature is a proof-of-ownership that can be used to support requirements for non-repudiation.

Data origin authentication can be addressed none exclusively at:

As for confidentiality, the link between the Data Origin Authentication and the PE consists of the fact that "data" specific integrity and authenticity security policy are enforced by the PE function which relies on the Data Origin Authentication service as PDP for that kind of policy. This kind of policy specifies, for a given data, assertions such as:

Thanks to the combination of these policies and the cryptographic mechanisms it is possible to support simple and very complex integrity and authenticity requirements.

Policy driven confidentiality and integrity improves the flexibility. It is the policy itself, assigned to a given data, that requires or not the need for (for instance) encryption. Security architecture just processes these policies therefore it is not responsible to specify which data are sensitive and which not.

Security audit is the process by which security-related events are recorded for real-time or differed analysis. The audit process typically involves the following phases:

The Audit function is limited to the audit generation; it allows (when needed, e.g. when non-repudiation is needed) to create, submit, persistently store and report on audit events. All these aspects are combined to proof of origin of data, proof of submission of data, proof of transport of data and proof of delivery of data.

The data collection and storage involves other part of the communication participant and therefore cannot be dedicated to the security architecture itself. The analysis and feedback is similarly performed by correlating security events coming from various sources.

The Audit-Function policy defines which events need to be audited and for which activities or resources.

Identity Management is a supporting infrastructure for maintaining and administering Digital Identities within organizations and/or communities, primarily for accessing resources such as services. It is essentially “user lifecycle management,” reflecting the creation, maintenance, and deletion of identities over time, where a “Digital Identity” is meant to consist of the following parts:

A Service Provider shall request a valid Digital Identity in order to be able to expose either an ATM specific service or an Enabling service. A Service Consumer needs to be identified in order to be authorized or not to consume such services.

From a functional viewpoint, identity management provides the following features:

Identity Management also helps to manage trust relationships between service consumers and service provider without a direct trust relationship between them, eliminating the need for each participant to independently manage their own trust relationships, as well as to have prior knowledge of one another in order to communicate.

Within each security domain the identity information are stored in an Identity Store also called Identity Registry. The Identity Management represents an abstraction layer to access to identity registries which forms a functional point of view can be seen as an entity providing CRUD operations on digital identities data.

The security policy represents a declarative way to describe which security functions need to be applied (enforced) in order to achieve desired level of security. Therefore the policy enforcement deals with the application of policies in security systems. The concept of policy enforcement is an architectural pattern for implementation of general cross cutting concerns; within the aviation architecture, policy enforcement might simplifies per OGC service endpoint definitions and maintenance of security relevant rules of communication.

The major functions within policy enforcement are the following:

From the Testbed-9, the OGC 09-035 three different approaches to identify communication participants and to implement access control specific for geospatial services:

This section explains the differences between network, transport and message based security and helps to understand the benefits and trade-offs of each security implementation approach. There are several conceptual and technical ways to implement these security aspects. Overall, transfer security might be achieved through the use of network, transport or message security:

The IT security functions of authentication, confidentiality and integrity can be implemented using either symmetric or asymmetric cryptography. The most obvious difference among them is that while the symmetric cryptography relies on the use of identical secret key material for complementary cryptographic operations, the asymmetric approach is based on the pairs of keys, the private and the public one. Both keys are always used for security operations but only the public key is distributed to the communication participants. Where symmetrical approach provides better performances, due to less expensive cryptographic operations (depends on introduced level of security, requested cryptographic operations might be executed several times for every single service invocation), it also means less flexibility. Secret keys must be distributed to the communication participants and this distribution needs to be secured very carefully.

Asymmetric approach has gained reasonable popularity (despite its lower performances), especially when the goal is to secure interactions among decoupled systems in a very dynamic IT environment.

Having said all that, we have two additional SWIM security architectural options for implementation of low level security functions (confidentiality, integrity check):

Both options can be used to implement network, transport or message security as they were evaluated in the previous section.

Symmetric cryptography requests the secret key distribution via trusted communication channel. Secret keys (trusted secret) might be distributed using alternative electronic or non-electronic communication channels considered as sufficiently secured. Symmetric keys might have validity period of several hours, days or even be generated without any expiration period. The share secrets and their validity range define the boundaries of security session, the security context. Symmetric cryptography based on short validity security sessions introduces more security, because the keys are reissued (and redistributed) more often. On the other side, the frequent keys distribution via dedicated trusted channels is not an efficient option for dynamic IT environments. It generates increased maintenance and administration efforts due to the need for secret keys distribution.

Symmetric cryptography based security option is combination of previous two. It specifies the compromise between shorter security context time to live and increased effort for the key distribution, which shorter validity periods would imply. In such scenario, the security session negotiation among consumers and provides is protected with asymmetric PKI and the information exchange is then secured using symmetric approach. The well-known example for such symmetric key material distribution protected by an asymmetric approach is the frequently used securing of end to end connection with TLS (transport level security). In order to establish one TLS communication session, the participant’s first exchanges security context related key material encrypted using their PKI public and private keys.

The TLS and similar methods work only for end to end connections. Considering the architectural options already listed for types of communication protection (the network, end to end and message), we additionally introduce an option for symmetric approach and message security style.

Generalizing this approach, we further refine options regarding the symmetric cryptography:

Second and third options listed here are specified in the WS-* based WS-Trust and WS-SecureConversation specifications. Second and third options are also envisaged in the DDS security standard being defined in Object management Group (OMG).

As an explanatory example, here is the depiction of the process of security context establishing using the dedicated security context broker. The example clearly depicts the assistance of the asymmetric PKI approach during the exchange of sensible security context material.

Once successfully negotiated, security context has validity for some period of time, for example, for several hours. During that validity period, the communication can repeatedly be secured with same key material, which is a quite efficient. If the key issuer services are federated, the security context could be extended to enclose additional services, even those operated by different providers, allowing service consumer to invoke all of them from within the boundary of single security session.

The choice between symmetric and asymmetric cryptography also influence the function of security authentication. The authentication among participants in an information exchange can occur either per interaction or per session. The authentication per interaction means that the authentication is executed again and again for every atomic interaction among systems, where the session based authentication will be performed only once for a number of interactions enclosed into security session scope. Considering the fact that typical security implementation based on symmetric cryptography establishes timely constrained security context (exchanging per session symmetric keys) and the fact that the authentication is always part of that process, it basically means that such approach also implements per session based authentication. The possession of session cryptographic material ensures mutual system authentication.

Security functions such as authentication and authorization can be put in place utilizing different standards and technical implementations, which might be applied at different levels of the ISO OSI reference model. This section provides introduction into information security taxonomy introduced as part of the Testbed-11 Common OGC Service Security.

The main objective of the Testbed-11’s security initiative was to describe Common Security for OGC Web Service standards. The Common Security has been found to require describing the constraints towards the following security requirements:

Authentication: ISO 10181-2 defines all basic concepts of authentication in Open Systems: It identifies different classes of authentication mechanisms, the services for their implementation and the requirements for supporting protocols. It further identifies requirements for the management of identity information.

Access Control: ISO 10181-3 defines all basic concepts for access control in Open Systems and the relation to other frameworks such as the Authentication and Audit Frameworks.

Non-repudiation: ISO 10181-4 refines and extends the concepts of non-repudiation, given in ISO 7598-2. It further defines general non-repudiation services and the mechanisms to provide these services.

Confidentiality: ISO 10181-5 defines the basic concepts of confidentiality, identifies classes of confidentiality mechanisms and their maintenance. It further addresses the interactions of the confidentiality mechanisms with other services.

Integrity: ISO 10181-6 defines the basic concepts of integrity, identical to the Confidentiality Framework.

Security Audits and Alarms: ISO 10181-7 defines the basic concepts for security audit and alarms and the relationship to other security services.

Following list provides outcomes from Testbed 11. It address the relevance for OGC compatible services and provides some implementation hints.

This chapter presents the extension proposal for a security architectures (as a special view on the overall testbed’s Aviation Architecture).

The Testbed 12 Aviation Architecture based on brokered service access and asynchronous communication with message brokers represents an example of an integration platform in a heterogenous communication SWIM environment. That implies complex requirements for security management. It includes several building blocks responsible (posses capabilities) for information exchange (messaging), service consumption, provisioning and discovery.

Further, there is a large messaging communication infrastructure operated by FAA, which shall be interoperable with the OGC web service ecosystem ( become accessible using the OGC Pub/SUB 1.0 asynchronous massaging standard). The fact that the aviation architecture deal with heterogenous message exchange patterns and many distinctive service provider and consumers (an intermediary component called broker inclusive) has the big implications on the security architecture.

In the global aviation business domain there is political, hierarchical structure, in which aviation stakeholders are organized and operates. In the most of cases the ANSP (aeronautical navigation service providers) maintain their own security domains and allow service consumers from own domain to consume services. Frequently, the countries operate one single aeronautical service provider organization (ANSP). In the USA the FAA is the national agency, which operates local SWIM and a single security domain. In Europe there are a numerous national ANSP, which operate their own security domains. Additionally, there is one service pool operated by Eurocontrol, which provides aeronautical services for all member countries.

More complex communication and thus security architectures might emerge with adoption of brand new requirements for interoperability between the USA and the EU also including other countries and regions. The challenge here will be to find the ways to provide largest possible interoperability with maximum of security and minimum security threats and operational difficulties.

In order to better understand the security we will introduce the concept of communication infrastructure, which includes all logical and physical resources put in place to enable the communication. This ER will also propose an extension for the aviation architecture in order to configure it to work in a security regular fashion and also be capable to support use cases scenarios which would include communication between autonomous security domains. Such use case might be very important in the future, when many aviation security domains worldwide become required to work interoperable providing an uniform way to access data and services.

The proposed security architecture provides several options based on security guidelines from Testbed-11.

Testbed-11 security taxonomy is based on traditional information security definition which includes a set of functions such as: confidentiality, integrity, availability, non-repudiation and so on. This engineering report will propose how to implement those functions. The proposals shall primarily depends on at which communication level the security was supposed to be implemented, whether we had to deal with one single or multiple security domains and what level of trust we anticipated in the communication between aviation service providers, service consumers and the Testbed-12 Aviation Architecture communication infrastructure.