Key Establishment during Application Start

advertisement
ACP WGN05 – WP 20
ACP SGN4 WP0402
Aeronautical Communication Panel
Working Group N – Networking
Subgroup N4 – Security
Montréal (Canada), 11 May – 20 May, 2005
Key Establishment during Application Start
Prepared By: FAA
SUMMARY
This paper describes how the ATN Application Security Solution may be invoked completely
within an application. This is compared to the previous general model where key establishment
is performed during Context Management (CM) and session-unique parameters are provided to
applications by CM. This approach does not change the ATN Application Security Solution but
merely offers alternative methods for invoking the solution. This approach does not obviate the
need for securing CM exchanges. This approach may be combined with the proposal for
applications to directly invoke System Security Object (SSO) services at the ULCS Dialogue
Service Boundary. CPDLC is used as an example application; however, the approach applies to
other applications as well.
1
Table of Contents
1
2
Introduction ............................................................................................................................. 3
Key Establishment by CM versus CPDLC Start .................................................................... 3
2.1
CM Key Establishment ................................................................................................... 3
2.2
CPDLC Start Key Establishment .................................................................................... 5
3
Considerations with Application Start Approach ................................................................... 5
3.1
CM Independence ........................................................................................................... 5
3.2
Operation without CM .................................................................................................... 6
3.3
Compatibility with Dialogue Service “Security Shim” Proposal ................................... 6
3.4
Certificate Management .................................................................................................. 6
4
Recommendation .................................................................................................................... 7
2
1
Introduction
The general model for the current ATN application security solution is that key establishment is
performed during a Context Management (CM) exchange, typically at CM Logon. During this
exchange session-unique parameters are derived and provided to Air/Ground Applications.
Air/Ground Applications in turn derive application-unique session keys. Using Controller Pilot
Data Link Communications (CPDLC) as an example, this paper describes an alternative to CM
based key establishment by performing key establishment during the start exchange. Note that
although CPDLC is used as an example, the alternative approach applies to any air/ground
application.
Section 2 provides a comparison of key establishment using CM and by CPDLC only.
Section 3 identifies some considerations with the Application Start approach.
Section 4 presents recommendations for the Working Group.
2
Key Establishment by CM versus CPDLC Start
2.1 CM Key Establishment
Figure 1A depicts an overview of the currently defined ATN security solution using CPDLC as
an example. Under the current solution keys are established by CM.
At Context Management logon, the aircraft computes (step 1) a digital signature for the Logon
Message. The signed CM Logon Message is sent (step 2) to the Ground CM. Upon receipt of
this message (step 3), the Ground CM retrieves the public key certificate for the aircraft and the
ground CPDLC application. The Ground CM validates that the certificates are authentic (signed
by the appropriate CA), and then using the retrieved aircraft public key verifies the signature on
the logon message. These operations provide the Ground CM assurance of the identity of the
airborne CM and assurance of the source and integrity of the logon message.
The Ground CM next (step 4) derives a Shared CM Session Key. The Ground CM then (step 5)
sends its own Public Key Certificate and the Ground CPDLC application’s public key in the CM
Response message with a Message Authentication Code. Upon receipt of this message (step 6),
the aircraft in turn derives (the same) Shared CM Session Key and using this key (step 7) checks
the CM Response message tag. This sequence of operations provides the aircraft CM assurance
of the identity of the ground CM and assurance of the source and integrity of the logon response
message. In addition, since the aircraft has authenticated the Ground CM, it is able to trust that
the CPDLC public key is authentic; that is, the aircraft trusts that the Ground CM has validated
the CPDLC Public Key Certificate.
3
1. Aircraft Signs CM Logon
Message
6. Aircraft derives
Shared CM Session Key
10. Aircraft CPDLC derives
Shared CPDLC Session Key
7. Aircraft authenticates CM
Response Message
Airborne CM
Airborne CPDLC
5. Ground CM sends:
it's Public Key Certificate
and CPDLC's public key
in a CM Response Message
with a
Message Authentication Code
2. Aircraft Sends
Signed CM Logon
Message
3.Ground CM
retrieves Aircraft
and Ground CPDLC
Public Key
Certificates and
authenticates the
CM Logon Message
Ground
Context
Management
(CM)
11. CPDLC Start and
subsequent Messages sent
with a
Message Authentication Code
Ground
CPDLC
8. Ground CPDLC retrieves sessionunique parameters to derive a Shared
CPDLC Session Key
9. Ground CPDLC derives a
Shared
CPDLC Session Key
4. Ground CM derives
Shared CM Session Key
Certificate
Directory
Figure 1A - CM Key Establishment
3. Airborne CPDLC
authenticates
CPDLC-start.req Message
Airborne CPDLC
4. Aircraft derives a Shared
CPDLC Session Key
2. Ground CPDLC sends:
it's Signing Public Key
Certificate and Key
Agreement Key
in a signed
CPDLC-start.req Message
5. Airborne
CPDLC sends
CPDLC-start.rsp
with a
Message
Authentication
Code
Certificate
Directory
8. Subsequent CPDLC Messages
sent with a
Message Authentication Code
Ground
CPDLC
1. Ground CPDLC retrieves
Aircraft Public Key Certificate
Signs
CPDLC-start.req Message
6. Ground CPDLC derives a Shared
CPDLC Session Key
7. Ground CPDLC authenticates
CPDLC-start.rsp Message
Figure 1B - CPDLC Key Establishment
4
In the CM Key Establishment case, CPDLC obtains (step 8) the public key of the aircraft along
with other key derivation data from CM. The Ground and Aircraft CPDLC applications are now
able to derive a shared Session Key using the ATN Key Agreement Scheme (steps 9 and 10).
Subsequent CPDLC messages are tagged with a Message Authentication Code, which is checked
by the peer (step 11). Both the Aircraft and Ground CPDLC applications are assured of the
source and integrity of each message.
2.2 CPDLC Start Key Establishment
Figure 1B depicts an overview of the ATN security solution where keys are established at
CPDLC Start.
At CPDLC Start (step 1), the Ground CPDLC retrieves the public key certificate for the aircraft
and computes a digital signature for the CPDLC Start request. The Ground CPDLC (Signing)
Public Key Certificate and key agreement key is sent (step 2) in a signed CPDLC Start request to
the aircraft. The Airborne CPDLC authenticates (step 3) the CPDLC Start Response message.
These operations provide the Airborne CPDLC assurance of the identity of the Ground CPDLC
and assurance of the source and integrity of the CPDLC Start request.
The Airborne CPDLC derives (step 4) a shared CPDLC Session Key and sends (step 5) a
CPDLC Start response with a Message Authentication Code. Upon receipt of this message, the
Ground CPDLC derives (step 6) the shared CPDLC Session Key and authenticates (step 7) the
CPDLC start response. This sequence of operations provides the Ground CPDLC assurance of
the identity of the Airborne CPDLC assurance of the source and integrity of the CPDLC Start
response message.
Subsequent CPDLC messages are tagged with a Message Authentication Code, which is checked
by the peer (step 8). Both the Aircraft and Ground CPDLC applications are assured of the source
and integrity of each message.
3
Considerations with Application Start Approach
Considerations with the Application Start approach depend firstly on the use of CM and secondly
whether the “Security Shim” which is possible with PM-CPDLC is also implemented in other
applications, including the CM application.
3.1 CM Independence
The basic notion of the CPDLC start approach in this paper is to provide an option to operate
CPDLC (or other applications) independent of CM. CM security as currently defined has
security processing at the application level (to uplink key agreement public keys and to provide
security parameters to other applications) and in the ULCS to protect actual CM exchanges.
Under the alternate approach described in this paper, CM would not perform security processing
5
at the application level, that is, CM would not act on behalf of applications to provide their
public keys to the aircraft and would not provide security parameters to applications.
The trade off with the Application Start approach is of course overhead. With the current ATN
security solution, exchange of certificates and associated signing and verifying operations are
performed (usually once) at CM. With the alternative approach this overhead is incurred every
time the Application Start service is invoked.
Note that it may be possible to exchange security parameters among Ground CPDLC
applications; however, this takes away the advantage of the Application Start approach.
Note further that it is assumed that the option for applications to support security would be
signaled during CM. In this case the CM exchange itself would still need to be authenticated.
3.2 Operation without CM
As a further consideration, given that the ICAO 24-bit address is added to flight plans, it may be
possible to operate CPDLC without CM. This would be a fundamental change to the CM
approach in the ATN Air/Ground environment and thus is beyond the scope of this paper.
However, the Application Start approach would permit security to still be applied in this
scenario.
3.3 Compatibility with Dialogue Service “Security Shim” Proposal
It was noted in previous meetings that it would be possible to invoke System Security Object
(SSO) services at the dialogue service boundary by inserting a “Security Shim” at this point.
The Security Shim is an alternative to implementing currently defined ULCS Security, that is, to
not implement the Security ASO and the embedded SESE.
The “Security Shim” furthermore takes advantage PM CPDLC in that the Message
Authentication Code is “XORed” with the application checksum in PM CPDLC. This eliminates
the need for additional bandwidth for the Message Authentication Code, which would otherwise
be required.
The alternative to perform key establishment at Application Start could be implemented within
the “Security Shim”. The net result would be that security could potentially be introduced
without change to the ULCS and without significant change to CM.
3.4 Certificate Management
Another consideration with the Application Start approach is certificate management. Under the
CM approach, Ground CM certificates are short-lived (on the order of 1 week) while application
certificates, e.g. Ground CPDLC certificates, are long-lived (on the order of 5 years). Shortlived certificates are used to address revocation since the aircraft does not have access to a
Certificate Revocation List (CRL). Providing short-lived certificates to a few Ground CM
6
systems is not a significant management issue; however, providing short-lived certificates to a
large number of applications may prove burdensome.
4
Recommendation
The working group is invited to comment on the alternative approach and identify further
considerations. The Working Group should then recommend whether the “Security Shim” and
“Key Establishment at Application Start” should be added to the Work Program to develop the
associated detailed Technical Provisions in ICAO Doc 9705. It is anticipated that modifications
would be required to SV 2 (CM), SV 4 (ULCS), and SV 8 (Security)
7
Download