ACP WGN SGN2 WP N2/4/10
03 May 2005
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WORKING GROUP N (NETWORKING)
SUB-GROUP N2 (AIR/GROUND APPLICATIONS)
Montreal, Canada, 11-12 May, 2005
Agenda Item 5.3 Review of Proposed Doc 9705 Section 4
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC
checksum algorithm
Presented by EUROCONTROL
Summary
This paper proposes SARPs and Guidance Material for inclusion in ICAO Doc
9705 Sub-Volume IV to include a default ATN Checksum Algorithm for use initially
by PM-CPDLC.
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC checksum algorithm
Ref : TRS054/T05/DEL/D04
TABLE OF CONTENTS
1.
2.
3.
Introduction .....................................................................................................................................1
1.1
Background ...............................................................................................................................1
1.2
References ................................................................................................................................1
Proposed Changes to Sub-Volume IV ...........................................................................................2
2.1
PM-CPDLC App-type registration .............................................................................................2
2.2
ATN Message Checksum .........................................................................................................2
Proposed Draft Guidance Material .................................................................................................3
3.1
Information included in the Scope of the Integrity Check .........................................................3
3.2
Choice of Integrity Check Algorithm ..........................................................................................4
3.3
Negotiation of the Integrity Check Algorithm.............................................................................5
Version: 0.A
Date: 03 May 2005
Page: ii
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC checksum algorithm
Ref : TRS054/T05/DEL/D04
1.
INTRODUCTION
1.1
Background
The development of PM-CPDLC requires a suitable integrity check algorithm to a)
generate the integrity check sequence to be included in protected messages, and b) to
verify the integrity check sequence in received data items.
A default algorithm than can be invoked by any ATN application is proposed for inclusion
in Doc 9705 Sub-Volume IV.
1.2
Version: 0.A
References
[1]
Manual of Technical Provisions for the Aeronautical Telecommunication Network
(ATN), ICAO Doc. 9705, Third Edition - 2002, Sub-Volume II: Air-Ground
Applications.
[2]
ACP/SGN2 WP N2/4/2 Proposed Doc 9705 Section 2.5 PM-CPDLC (.pdf) –
Proposed V1.1 input Montreal
Date: 03 May 2005
Page: 1
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC checksum algorithm
Ref : TRS054/T05/DEL/D04
2.
PROPOSED CHANGES TO SUB-VOLUME IV
2.1
PM-CPDLC App-type registration
Application types are registered in ICAO Doc 9705 Sub-Volume IX. However, for historical reasons,
the application type defections are also reproduced in Sub-Volume IV.
Add the following row to table 4.3-2
Protected Mode CPDLC
2.2
PCPC (22)
ATN Message Checksum
In order to make the common checksum computation and verification processing available in a
consistent way for all ATN applications, a new major section (4.10) is proposed for the Upper Layer
Communications Service in SV4. (For the second Edition, it will be necessary to add placeholders for
sections 4.7 – 4.9)
4.10
ATN Message Integrity Check Sequence
Note.- The integrity check algorithm specified in this section may optionally be invoked by the ATN
Application User specification to provide a proof of message integrity. If other information (e.g. sender
and/or receiver identity) is also bound to the message when the integrity sequence is computed and
verified then it can also provide additional proofs (e.g. a proof of delivery to an intended recipient).
4.10.1 By default, an application Integrity Check shall be computed using the Default ATN Message
Checksum algorithm as specified in 4.10.2.
Note.—Other Integrity Check algorithms may be used and their use identified by including, in
the application message, a Relative OID that identifies the algorithm alongside the computed
Integrity Check. However, the use of an alternative Integrity Check algorithm must be agreed
in advance by both air and ground users using a procedure outside of the scope of this
specification.
4.10.2 Default ATN Message Checksum algorithm
Note 1.— The Default ATN Message Checksum algorithm generates a 32 bit (4 octet)
checksum.
Note 2.—The Default ATN Message Checksum algorithm is a 32 bit version of the Fletcher
algorithm. This has been chosen in order to satisfy requirements for high data integrity with
good performance characteristics.
Note 3.—The object identifier "atn-default-checksum" as defined below identifies the Default
ATN Message Checksum algorithm :
atn-default-checksum ::= OBJECT IDENTIFIER {iso(1) identified organisation (3)
icao(27) atn-algorithms(9) atc-chk32(0)}
4.10.2.3
Symbols
Note 1.— The symbols used in this specification are as follows:
C0, C1, C2, C3 are variables used by the algorithm.
i is the number (i.e. position) of an octet within the Message to be protected
L
is the length of the Message to be protected, in octets.
Xj
is the value of the j'th octet of the checksum BIT STRING, where X0 is the
first octet in the BIT STRING, X1 is the second, X2 is the third and X3 is the fourth
octet.
Note 2.—The Message to be protected is a bit string provided by the user of this algorithm
4.10.2.4
Arithmetic Conventions
4.10.2.4.1 Addition shall be performed in one of the two following modes:
Version: 0.A
Date: 03 May 2005
Page: 2
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC checksum algorithm
Ref : TRS054/T05/DEL/D04
a) modulo 255, or
b) ones complement arithmetic
4.10.2.4.2 In the ones complement mode, if any of the variables has the value minus zero (i.e.
0xFFFF), it shall be regarded as though it were plus zero (i.e. 0).
4.10.2.5
Algorithm for Checksum Generation
4.10.2.5.1 If the message to be protected is not an integral number of octets, it shall be right
padded with '0' bits to the next octet boundary.
4.10.2.5.2 The ATN Message checksum shall be generated by the following algorithm.
a. Initialise C0, C1, C2 and C3 to zero
b. Process each octet in the Message sequentially from i = 1 to L by
1) adding the value of the octet to C0; then
2) adding the value of C0 to C1, C1 to C2, and C2 to C3
c. Set the octets of the checksum as follows:
1) X0 = - (C0 + C1 + C2 + C3)
2) X1 = C1 + 2*C2 + 3*C3
3) X2 = - (C2 + 3*C3)
4) X3 = C3
4.10.2.6
Algorithm for Checksum Verification
4.10.2.6.1 When the integrity of a message is to be verified using this algorithm, the
verification function shall:
a) Append to the Message the octets of the checksum field in the same order in which
they appear in the checksum BIT STRING.
b) Initialise C0, C1, C2 and C3 to zero
c) Process each octet in the Message, including the appended checksum octets,
sequentially from i = 1 to L by
i)
adding the value of the octet to C0; then
ii)
adding the value of C0 to C1, C1 to C2, and C2 to C3
d) Discard the appended checksum octets.
e) If, when all the octets have been processed, all of the variables C0, C1, C2 and C3
have the value zero, then a "success" indication is given to the algorithm user .
Otherwise, a "verification failure" indication is given to the algorithm user.
3.
PROPOSED DRAFT GUIDANCE MATERIAL
The following text is proposed as additional Guidance Material for Sub-Volume IV.
3.1
Information included in the Scope of the Integrity Check
This check is a message digest or checksum that is computed from a canonically-encoded bit steam
provided by the user of the integrity check mechanism.
For example, for PM-CPDLC, the user provides an encoded ASN.1 sequence comprising:
Version: 0.A

the PER encoded CPDLC message,

the Flight ID

the 24-bit ICAO Address
Date: 03 May 2005
Page: 3
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC checksum algorithm
Ref : TRS054/T05/DEL/D04

the Ground Facility Designation of the ATSU

The CPDLC ASE Version Number.
This Integrity Check is then transferred along with the message. Note that the CPDLC message does
not itself include the Flight ID, 24-bit ICAO Address, Ground Facility Designation, or the CPDLC ASE
Version Number. These are only used for the purposes of creating and verifying the Integrity Check.
By verifying the Integrity Check, the receiver gains a proof that it is in agreement with the sender on
the value of the Flight ID, 24-bit ICAO Address, Ground Facility Designation, and the CPDLC ASE
Version Number. For example, a controller may decide to uplink a clearance to a given Flight identified
by its Flight ID. The ground system looks up the Flight Plan to determine the 24-bit ICAO Address of
the aircraft and then generates the Integrity Check over the message, using the ASE Version Number,
the ATSU’s Ground Facility Designation, the Flight ID selected by the controller and the 24-bit ICAO
Address recorded in the Flight Plan as a result of the CM Logon. It then selects the appropriate
transport connection and uplinks the message.
When the message is received by the aircraft, the Integrity Check is verified using the Flight ID as
currently specified by the pilot, the configured 24-bit ICAO Address, the Ground Facility Designation of
the Data Authority, and the ASE Version Number. As long as these are the same as used by the
ground when the Integrity Check was generated, then the Integrity Check will be verified and a proof is
obtained that the message has been delivered to the intended aircraft.
On the other hand, if an error occurs in the processing or distribution of CM Logon information, or the
transport connection selection, then the message may arrive at the wrong aircraft. The receiving
aircraft will use a different value for the Flight ID, 24-bit ICAO Address, or both, and Integrity Check
verification will fail. Any hazard occurring as a result of these errors is thus mitigated by the verification
of the Integrity Check. Due to the independent nature of the Integrity Check, no reliance has to be
placed on the dynamic linkage between Flight ID and the identity of the aircraft operating the Flight,
maintained through CM Logon and the Ground Systems.
It is now also possible to distribute CM Logon information on the ground, and meet the Safety
Objectives, as any failure to update this information will also result in an Integrity Check verification
failure and hence such an error, although undesirable, is not a hazard.
The Data Authority’s Ground Facility Designation is also included in the scope of the Integrity Check.
This adds no protocol overhead to CPDLC but will detect any error due to avionics or the air/ground
communications service mixing up transport connections to the CDA, NDA or DSA. This adds
robustness and may simplify avionics design.
The CPDLC ASE Version Number is also included in the scope of the Integrity Check. The ground and
airborne users must use the same ASE Version if there is not to a be risk that messages may be
incorrectly decoded. The ASE Version is checked when the CPDLC Start is processed. However, the
integrity of the ASE Version Number exchanged on a CPDLC Start is outside of the scope of the
CPDLC Integrity Check and the Safety Case will need to rely on the data integrity provided by the
transport protocol if this check is to be relied on for safety purposes. Including the CPDLC ASE
Version Number in the scope of the Integrity Check adds no protocol overhead and is a robust solution
that may usefully avoid having to depend upon correct operation of the transport protocol.
3.2
Choice of Integrity Check Algorithm
The default algorithm for the application Integrity Check is a 32-bit version of the Fletcher algorithm.
The 16-bit version of the Fletcher algorithm is well known as the checksum algorithm for TP4 and has
been well researched. It is understood to have an undetected error rate better than 1 in 105 (fraction of
all errors detected).
The 32-bit version of the Fletcher algorithm is already in use by ICAO SARPs for the extended
Transport Checksum, and is based on Fletcher’s original paper:
“An Arithmetic Checksum for Serial Transmission” – IEEE Transactions on Communications – January
1982.
Fletcher’s analysis implies that this version of the checksum has an undetected error rate of better
than 1 in 1010.
Version: 0.A
Date: 03 May 2005
Page: 4
Proposed Doc 9705 Updated Sub-volume IV for PM-CPDLC checksum algorithm
Ref : TRS054/T05/DEL/D04
The 32-bit checksum is preferred over the 16-bit checksum as an undetected error rate better than 1
in 105 is not believed to be sufficient for remote hazards.
3.3
Negotiation of the Integrity Check Algorithm
All compliant implementations support the default algorithm. Compliancy to other algorithms is a
matter for later versions of the specification or for regional implementations.
Other Integrity Check algorithms may be specified in the future and the specification is extensible to
include any such algorithm. New Integrity Check algorithms may be proposed to change the
information included in the scope of the Integrity Check and hence the proof offered on Integrity Check
verification. Cryptographic checksum algorithms may also be proposed to provide authentication and a
proof that the message has not been modified.
Version: 0.A
Date: 03 May 2005
Page: 5