1、 TIA-102.AACD-A (Revision of TIA-102.AACD) September 2014Project 25 Digital Land Mobile Radio- Key Fill Device (KFD) Interface Protocol NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchase
2、rs, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA
3、from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are adopted by TIA in accordanc
4、e with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems asso
5、ciated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. Any use of trademarks in this document are for inform
6、ation purposes and do not constitute an endorsement by TIA or this committee of the products or services of the company. (From Project No. TIA-PN-102.AACD-A, formulated under the cognizance of the TIA TR-8 Mobile and Personal Private Radio Standards, TR-8.3 Subcommittee on Encryption). Published by
7、TELECOMMUNICATIONS INDUSTRY ASSOCIATION Technology (b) there is no assurance that the Document will be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The us
8、e or practice of contents of this Document may involve the use of intellectual property rights (“IPR”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applicat
9、ions are claimed and called to TIAs attention, a statement from the holder thereof is requested, all in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a
10、party to discussions of any licensing terms or conditions, which are instead left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or prov
11、ided in the Manual have been complied with as respects the Document or its contents. If the Document contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a st
12、andard, specification, recommendation or otherwise), whether such reference consists of mandatory, alternate or optional elements (as defined in the TIA Procedures for American National Standards) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for
13、 IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encouragement of voluntary disclosure (see TIA Procedures for American National Standards Annex C.1.2.3) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as t
14、o claims of IPR in the records or publications of the other SSO shall not constitute identification to TIA of a claim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or
15、otherwise investigate products, designs or services or any claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PA
16、RTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABL
17、E STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CO
18、NTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT
19、 LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. TIA 102.AACD-A 3 Table of Contents 1 INTRODUCTION . 11
20、 1.1 Purpose. 11 1.2 Scope 11 1.3 Revision History 11 1.4 References 11 1.5 Definitions, Acronyms, and Abbreviations . 12 2 MANUAL REKEYING OVERVIEW 14 2.1 KFD Based Key Management . 14 2.2 KMF Based Key Management 15 2.3 Manual Rekeying Features . 15 2.3.1 Keyload . 15 2.3.2 Key Erase 16 2.3.3 Eras
21、e All Keys . 16 2.3.4 View Key Info 16 2.3.5 View Individual RSI . 16 2.3.6 Load Individual RSI . 16 2.3.7 View KMF RSI . 16 2.3.8 Load KMF RSI . 17 2.3.9 View MNP . 17 2.3.10 Load MNP . 17 2.3.11 View Keyset Info 17 2.3.12 Activate Keyset 17 2.4 Manual Rekeying Features for Authentication 17 2.4.1
22、Load Authentication Key . 17 2.4.2 Delete Authentication Key . 18 2.4.3 View SUID Info 18 2.4.4 View Active SUID Info . 18 3 INTERFACE PROTOCOL DEFINITION 19 3.1 KFD-MR Interface . 19 3.2 Physical Layer (RS232) 20 3.3 Physical Layer (USB) 20 3.4 Link Layer . 20 3.5 Network Layer . 20 3.6 Transport L
23、ayer . 21 3.7 KFD Interface Protocol Application Sublayer 21 3.7.1 Message Format . 21 3.7.2 Exchange Procedure . 22 3.8 Manual Rekeying Application Sublayer . 26 3.8.1 Keyload . 26 3.8.2 Load Individual RSI . 28 3.8.3 Load KMF RSI . 29 3.8.4 Load MNP . 30 3.8.5 Erase Keys 31 3.8.6 Erase All Keys .
24、33 TIA 102.AACD-A 4 3.8.7 View Key Info 33 3.8.8 View Individual RSI . 34 3.8.9 View KMF RSI . 35 3.8.10 View MNP . 36 3.8.11 View Keyset Info . 37 3.8.12 Activate Keyset . 38 3.8.13 Load Authentication Key . 39 3.8.14 Delete Authentication Key . 40 3.8.15 View SUID Info 41 3.8.16 View Active SUID I
25、nfo . 42 3.9 KMMs . 43 3.9.1 KMM Header Definition . 44 3.9.2 KMM Body Definitions . 45 3.9.2.1 Change-RSI-Command . 45 3.9.2.2 Change-RSI-Response . 45 3.9.2.3 Changeover-Command . 45 3.9.2.4 Changeover-Response 45 3.9.2.5 Inventory-Command (List Active Kset IDs) 45 3.9.2.6 Inventory-Response (List
26、 Active Kset IDs) 45 3.9.2.7 Inventory-Command (List RSI Items) 45 3.9.2.8 Inventory-Response (List RSI Items) . 46 3.9.2.9 Inventory-Command (List Keyset Tagging Info) 46 3.9.2.10 Inventory-Response (List Keyset Tagging Info) . 46 3.9.2.11 Inventory-Command (List Active Keys) . 46 3.9.2.12 Inventor
27、y-Response (List Active Keys) 47 3.9.2.13 Inventory-Command (List MNP) 47 3.9.2.14 Inventory-Response (List MNP) 47 3.9.2.15 Inventory-Command (List KMF RSI) 47 3.9.2.16 Inventory-Response (List KMF RSI) 48 3.9.2.17 Modify-Key-Command . 48 3.9.2.18 Negative-Acknowledgment 50 3.9.2.19 Rekey-Acknowled
28、gment 50 3.9.2.20 Zeroize-Command . 51 3.9.2.21 Zeroize-Response . 51 3.9.2.22 Load-Config-Command . 51 3.9.2.23 Load-Config-Response 51 3.9.2.24 Unable to Decrypt Response . 51 3.9.2.25 Load Authentication Key Command . 52 3.9.2.26 Load Authentication key Response 54 3.9.2.27 Delete Authentication
29、Key Command . 56 3.9.2.28 Delete Authentication Key-Response 57 3.9.2.29 Inventory-Command (List SUID Items) 58 3.9.2.30 Inventory-Response (List SUID Items) 59 3.9.2.31 Inventory-Command (List Active SUID) . 60 3.9.2.32 Inventory-Response (List Active SUID) . 60 3.9.2.33 Session Control KMM 61 TIA
30、102.AACD-A 5 Annex A (Normative): CRC Generation (Register multicast and broadcast traffic is not used. Time-to-Live (TTL), Type of Service (TOS), and Precedence fields within IP headers are set to default values. See Reference 11 for additional details. The KFD learns the necessary IP addressing in
31、formation from the MR during establishment of PPP connectivity. TIA 102.AACD-A 21 3.6 Transport Layer UDP is used for the transport layer (see Reference 10). The MR expects to receive communications from a Key Fill Device on a configured UDP port, the default is 49165 as defined in TIA 102.BAJD Refe
32、rence 7. The KFD shall therefore use this as the destination port for messaging to the MR. The source port for messages sent by the KFD and MR shall be selected by the MR and Key Fill Device. The valid range for the source port is 49165 65535. This may be the same as the port the MR expects to recei
33、ve communications on. The destination UDP port for messages sent by the Key Fill Device is established through configuration in the Key Fill Device prior to connection establishment. The supported range for the destination port is 49165 - 65535. The MR uses the source port in messaging received from
34、 the Key Fill Device as the destination port for messaging sent to the Key Fill Device. Minimally the destination port in the Key Fill Device needs to be configured to be the same as the listening port in the MR. UDP checksums, as described in reference 10, shall be used for error detection. 3.7 KFD
35、 Interface Protocol Application Sublayer The purpose of the KFD Interface Protocol is to provide a method for exchanging Key Management Messages (or KMMs) on the KFD interfaces. KMM Datagrams are used to deliver KMMs over the interface. The format of the KMM Datagram permits encryption. The encrypti
36、on format for KMMs is defined in reference 1. The KFD Interface Protocol also defines the procedure for the exchange of KMMs between the KFD and MR. This exchange procedure is referred to as an exchange session. During an exchange session, the KFD and MR can alternate roles of originator and recipie
37、nt of KMM Datagrams. After a device sends a KMM Datagram on the interface, it shall go into receive to accept a KMM Datagram. Only then can it send a subsequent KMM Datagram. 3.7.1 Message Format The Data Link Independent KMM datagram is used as the message format for the KFD interface protocol. Whe
38、n the KMM datagram is transmitted, the first field in each message body is transmitted first, the most significant octet in each field is transmitted first, and the most significant bit in each octet is transmitted first. TIA 102.AACD-A 22 Figure 4. Data Link Independent KMM Datagram The KMM Preambl
39、e and KMM are defined in reference 1. 3.7.2 Exchange Procedure This section defines the exchange procedure, referred to as an exchange session that is used by the KFD Interface protocol. The protocol divides the exchange session into five parts. Refer to Figure 5. 1) Establish Session 2) KMM transfe
40、r from KFD to MR 3) KMM transfer from MR to KFD 4) Terminate Session 5) Disconnect Step 1: The Establish Session handshake allows endpoint device type identification and shall be initiated by the KFD. The KFD sends a Session Control KMM containing the Session Control Opcode for Ready Request and Sou
41、rce Device Type for KFD. If the MR is capable of exchanging information with the KFD and is listening for a Session Control KMM, the MR responds with a Session Control KMM containing the Session Control Opcode for Ready General Mode and Source Device Type for MR, else it does not respond. If the KFD
42、 does not receive a response within 5 seconds, or if the KFD receives an invalid response, the KFD considers itself to be disconnected from the MR. If the proper response is received, the KFD considers itself to be connected, and the exchange session proceeds to step 2. Note: Upon responding with a
43、Session Control KMM, the MR should consider itself to be connected to the KFD until the KFD initiates logical disconnection (step 5) or as long as a general inactivity timer remains active. This MR timer is called the Key Fill Inactivity Timer (KIT). The length of the KIT may be configurable, its de
44、fault value shall be 15 seconds, its minimum value shall be 5 seconds and its maximum value shall be 30 seconds. The KIT should be started in the MR upon sending a Session Control KMM to the KFD. The KIT is reset every time the MR sends a KMM to the KFD in subsequent steps. If its KIT KMM Datagram K
45、MM KMM Preamble TIA 102.AACD-A 23 expires, the MR considers itself to be disconnected, and takes no further action, and will only respond to a subsequent Session Control KMM containing the Session Control Opcode for Ready Request and Source Device Type for KFD. Step 2: The KFD now transfers any and
46、all KMMs queued for this MR. To minimize the memory requirements of the MR, the KFD transfers the KMMs one at a time waiting for a reply after each transfer. The MR replies with a KMM datagram containing the appropriate response KMM. Once all KMMs have been transferred, the KFD sends a Session Contr
47、ol KMM containing the Session Control Opcode for Transfer Done and the Source Device Type for KFD indicating to the MR that it has completed its transfer. The exchange session now moves to step 3. Note: If the KFD does not receive a valid KMM from the MR within 5 seconds, the KFD terminates the sess
48、ion (see step 4) and may attempt to initiate another session in the manner described in step 1. Step 3: The MR now transfers any and all KMMs queued for the KFD in the same manner as step 2. The MR transfers the KMMs one at a time waiting for a reply after each transfer. The KFD replies with a KMM d
49、atagram containing the appropriate response KMM. Once all KMMs have been transferred, or if there are no KMMs to transfer, the MR sends a Session Control KMM containing the Session Control Opcode for Transfer Done and Source Device Type for MR to indicate to the KFD that it has completed its transfer. The exchange session now moves to step 4. Step 4: The KFD now terminates the session by sending a Session Control KMM containing the Session Control Opcode for End Session and Source Device Type for KFD to the MR. In response, the MR sends a Session Control KMM containi
