Secure Communications Interoperability Protocol
This article includes a list of general references, but it lacks sufficient corresponding inline citations. (October 2015) |
The Secure Communications Interoperability Protocol (SCIP) is a US standard for secure voice and data communication, for circuit-switched one-to-one connections, not packet-switched networks. SCIP derived from the US Government Future Narrowband Digital Terminal (FNBDT) project.[1] SCIP supports a number of different modes, including national and multinational modes which employ different cryptography. Many nations and industries develop SCIP devices to support the multinational and national modes of SCIP.
SCIP has to operate over the wide variety of communications systems, including commercial land line telephone, military radios, communication satellites, Voice over IP and the several different cellular telephone standards. Therefore, it was designed to make no assumptions about the underlying channel other than a minimum bandwidth of 2400 Hz. It is similar to a dial-up modem in that once a connection is made, two SCIP phones first negotiate the parameters they need and then communicate in the best way possible.
US SCIP or FNBDT systems were used since 2001, beginning with the CONDOR secure cell phone. The standard is designed to cover wideband as well as narrowband voice and data security.
SCIP was designed by the Department of Defense Digital Voice Processor Consortium (DDVPC) in cooperation with the U.S. National Security Agency and is intended to solve problems with earlier NSA encryption systems for voice, including STU-III and Secure Terminal Equipment (STE) which made assumptions about the underlying communication systems that prevented interoperability with more modern wireless systems. STE sets can be upgraded to work with SCIP, but STU-III cannot. This has led to some resistance since various government agencies already own over 350,000 STU-III telephones at a cost of several thousand dollars each.
There are several components to the SCIP standard: key management, voice compression, encryption and a signalling plan for voice, data and multimedia applications.
Key Management (120)
[edit]To set up a secure call, a new Traffic Encryption Key (TEK) must be negotiated. For Type 1 security (classified calls), the SCIP signalling plan uses an enhanced FIREFLY messaging system for key exchange. FIREFLY is an NSA key management system based on public key cryptography. At least one commercial grade implementation uses Diffie-Hellman key exchange.
STEs use security tokens to limit use of the secure voice capability to authorized users while other SCIP devices only require a PIN code, 7 digits for Type 1 security, 4 digits for unclassified.
Voice compression using Voice Coders (vocoders)
[edit]SCIP can work with a variety of vocoders. The standard requires, as a minimum, support for the mixed-excitation linear prediction (MELP) coder, an enhanced MELP algorithm known as MELPe, with additional preprocessing, analyzer and synthesizer capabilities for improved intelligibility and noise robustness. The old MELP and the new MELPe are interoperable and both operate at 2400 bit/s, sending a 54 bit data frame every 22.5 milliseconds but the MELPe has optional additional rates of 1200 bit/s and 600 bit/s.
2400 bit/s MELPe is the only mandatory voice coder required for SCIP. Other voice coders can be supported in terminals. These can be used if all terminals involved in the call support the same coder (agreed during the negotiation stage of call setup) and the network can support the required throughput. G.729D is the most widely supported non-mandatory voice coder in SCIP terminals as it offers a good compromise between higher voice quality without dramatically increasing the required throughput.
Encryption (SCIP 23x)
[edit]The security used by the multinational and national modes of SCIP is defined by the SCIP 23x family of documents. SCIP 231 defines AES based cryptography which can be used multinationally. SCIP 232 defines an alternate multinational cryptographic solution. Several nations have defined, or are defining, their own national security modes for SCIP.
US National Mode (SCIP 230)
[edit]SCIP 230 defines the cryptography of the US national mode of SCIP. The rest of this section refers to SCIP 230. For security, SCIP uses a block cipher operating in counter mode. A new Traffic Encryption Key (TEK) is negotiated for each call. The block cipher is fed a 64-bit state vector (SV) as input. If the cipher's block size is longer than 64 bits, a fixed filler is added. The output from the block cipher is xored with the MELP data frames to create the cipher text that is then transmitted.
The low-order two bits of the state vector are reserved for applications where the data frame is longer than the block cipher output. The next 42 bits are the counter. Four bits are used to represent the transmission mode. This allows more than one mode, e.g. voice and data, to operate at the same time with the same TEK. The high-order 16 bits are a sender ID. This allows multiple senders on a single channel to all use the same TEK. Note that since overall SCIP encryption is effectively a stream cipher, it is essential that the same state vector value never be used twice for a given TEK. At MELP data rates, a 42-bit counter allows a call over three thousand years long before the encryption repeats.
For Type 1 security, SCIP uses BATON, a 128-bit block design. With this or other 128-bit ciphers, such as AES, SCIP specifies that two data frames are encrypted with each cipher output bloc, the first beginning at bit 1, the second at bit 57 (i.e. the next byte boundary). At least one commercial grade implementation uses the Triple DES cipher.
Signalling plan (210)
[edit]The SCIP signalling plan is common to all national and multinational modes of SCIP. SCIP has two mandatory types of transmission. The mandatory data service uses an ARQ protocol with forward error correction (FEC) to ensure reliable transmission. The receiving station acknowledges accurate receipt of data blocks and can ask for a block to be re-transmitted, if necessary. For voice, SCIP simply sends a stream of voice data frames (typically MELPe frames, but possibly G.729D or another codec if that has been negotiated between the terminals). To save power on voice calls, SCIP stops sending if there is no speech input. A synchronization block is sent roughly twice a second in place of a data frame. The low order 14 bits of the encryption counter are sent with every sync block. The 14 bits are enough to cover a fade out of more than six minutes. Part of the rest of the state vector are sent as well so that with receipt of three sync blocks, the entire state vector is recovered. This handles longer fades and allows a station with the proper TEK to join a multi station net and be synchronized within 1.5 seconds.
Availability
[edit]As of March 2011[update] a range of SCIP documents, including the SCIP-210 signalling standard, are publicly available from the IAD website.[2]
Prior to this, SCIP specifications were not widely diffused or easily accessible. This made the protocol for government use rather "opaque" outside governments or defense industries. No public implementation of the Type 1 security and transport protocols are available, precluding its security from being publicly verified.
See also
[edit]- Secure voice
- ZRTP
- MELP
- MELPe
- CVSD
- CELP
- LPC-10e
- FS1015
- FS1016
- ANDVT
- Secure Terminal Equipment
- L-3 Omni/Omni xi
- Sectéra secure voice family
Notes
[edit]- ^ Introduction to FNBDT Archived 2016-11-04 at the Wayback Machine by NC3A discusses the prospects for FNBDT for NATO in 2003
- ^ SCIP-related documents are made available through the Information Assurance Directorate web site. Documents can be retrieved by typing "SCIP" into the IAD SecurePhone document search web page
References
[edit]- Securing the Wireless Environment (FNBDT), briefing available from http://wireless.securephone.net/
- Secure Communications Interoperability Protocols, SCIP, HFIA briefing available at https://web.archive.org/web/20060530160027/http://www.hfindustry.com/Sept05/Sept2005_Presentations/HFIAbriefing.ppt