Major Voice Security protocol Review Voice Security Protocol Review An overview of all major voice security protocols like never done Fabio Pietrosanti (naif) Email:  [email_address] Blog:  http://infosecurity.ch
Agenda: Mission impossible in 1 hour? 1 – Understanding voice encryption 2 – Mobile TLC industry standards 3 - Government and Military standards 4 - Public Safety standards 5 - IETF VoIP Security standards 6 - Various anti-wiretapping secure phones 7 - Conclusion From this talk you will learn a lot about: Different requirements among voice encryption technologies Major voice encryption standards
Who am i Fabio Pietrosanti Works in IT Sec till ’98 Stay in digital underground with nickname “naif” till ’95 Worked as network security manager for I.NET SpA, Security Advisor Corporate Security Telecom Italia Now CTO of KHAMSA ITALIA SPA doing voice encryption stuff http://www.privatewave.com Project and engineer strong encryption products and technologies for VOICE Technology partnership with Philip Zimmermann Participate to underground communities, sikurezza.org, s0ftpj, metro olografix, progetto winston smith, etc
Being founder and CTO of a company doing voice encryption this presentation follow my view on encryption and security/wiretapping technologies My personal and professional feeling are about voice crypto are philosophically near to openness, standardization open-source, open and transparent peer review and i hate every closed and proprietary solution This presentation try to be as much as objective as possible
5 Overview of voice encryption systems
Communication technologies Traditional telephony (circuit switched) ISDN (fixed) PSTN (fixed) GSM/CDMA/UMTS (mobile) SAT (iridium, turaya, inmarsat, etc) VoIP Telephony (packet switched) Softphone on PC Hardware phones Mobile internet (GPRS, EV-DO, EVDO, etc) Radio transmission HF, UHF, EHF, VLF (air, space, earth, sea) Understanding voice encryption
Authorities for standards ISO ITU-T GSM Consortium 3GPP 3GPP2 NSA NATO IETF Telecom Industry Association (US interim standards) Understanding voice encryption
Result of complexity in technologies and authorities NO single standard for telephony NO single standard for security (not even enough!) And most persons just think that only Internet exists…! Understanding voice encryption
Digital vs. Analog Scrambling Vs. Encryption Analog connection Vs. Digital connection Creating a digital data path over the media And what about the signaling? Outband signaling Inband signaling Best review of scrambling technologies with security evaluation:  https://upcommons.upc.edu/pfc/bitstream/2099.1/4858/1/MarkusBrandau.pdf Understanding voice encryption
TLC Communication technologies But bear in mind military and public safety requirement: Radio from ELF (3-3000hz) to EHF (30-300ghz) Understanding voice encryption Data Transmission Circuit Switched Packet Switched ISDN, GSM,CDMA,UMTS, PSTN, SAT VoIP Quality of service Granted GPRS / EDGE / UMTS Not Granted Coverage Full Only Urban Area Billing Per-second (sender pay) Per-packet (sender/receiver pay) Signaling Outband In-band (over IP)
Different use case and requirements Government (embassies and agencies) and Military (battlefield, earth, air, sea) Public safety Mobile Telecommunication industry IETF standards Misc use anti-wiretapping secure phone Understanding voice encryption
Major technology summary Understanding voice encryption Use case Technology End-To-Site Security End-to-En Security Government and Military SCIP Yes Yes Public Safety TETRA Yes Yes  (optional) Mobile Industry GSM UMTS LTE Yes No IETF (Internet) SRTP/SDES SRTP/ZRTP Yes Yes
Different security model End-to-end Security point-to-point point-to-multipoint End-to-site Mixed setup Understanding voice encryption
Security of crypto operation Tamper proof encryption key container (SIM Card) Tamper proof enciphering hardware (NSA / NATO Crypto Card) Embedded hw/sw encryption along with tlc equipment General Trusted operating system General operating system Embedded custom (firmware) operating system False sense of security using old concepts Jtag debugging & reversing are currently diffused Firmware can be broken if not protected with trusted hardware Understanding voice encryption
Standards vs Proprietary Moving from a cold-war to multilateral operations bring to standardization and interoperability requirements Proprietary technology Require gateway for interoperability breaking end-to-end security Increase delay High costs Single vendor dependency Standards and open technologies Standards but closed technologies Standards but partially closed technologies Understanding voice encryption
NSA Cryptographic Modernization Program Moving from proprietary to standard solution Interoperate with NATO and coalition Replacing 1.3milion encryption units in 10 years Avoid dependency on single vendor  Reduce costs Update all equipments to modular crypto systems Not anymore single crypto system but modular upgradable systems Understanding voice encryption
The race to standardization Mobile TLC industry: GSM 2G:  A5/1 , A5/2,  A5/3 GPRS 2.5G: GEA1, GEA2, GEA3 UMTS 3G: UEA1, UEA2 UMA/GAN: IPSEC with IKEv2 / AES LTE 4G: 128-EEA1, 128-EEA2, 128-EEA3 Government and Military: SCIP / FBNDT Public safety:  TETRA IETF Standard: SIP/RTP (SRTP -> SDES / ZRTP / DTLS) Secure Phone: Still plenty of various proprietary solution Understanding voice encryption
Beware of Snake Oil Crypto Staying careful about snake oil encryption Bruce Schneier and Phil Zimmermann reference Snake Oil Encryption is Secret Algorithm Algorithm without key exchange details Security Expert review and useless certificates Unbreakable Unsubstantiated bit claims Not explaining the security model (end-to-end vs end-to-site) http://en.wikipedia.org/wiki/Snake_oil_(cryptography ) http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Understanding voice encryption
Mobile TLC Industry GSMA / 3GPP / LTE
Security by lobbying and patenting Mobile TLC industry TLC industry is represented mainly by large corporation Each standard is defined inside defined organization with the direct industry participation Standards are specifically defined in a cryptic and complex document formats Standards in mobile environment are very often plenty of patented methodologies Even if we refer always to “GSM” there are a lot of GSM releases Information is fragmented and the “Algorithm” custodian concept prevent immediate use for research http://gsmworld.com/our-work/programmes-and-initiatives/fraud-and-security/gsm_security_algorithms.htm
2G: GSM encryption Mobile TLC industry Operate at Layer1 Provide one-way mobile to network authentication Provide mobile-to-BTS encryption A wide set of algorithms A5/0 (no encryption) A5/1 (standard encryption) A5/2 (export version, weak) A5/3 (Use of Kasumi in GSM) Given the peculiarity of the overall protocol all GSM communication can be broken, even with an upgrade to A5/3, because interoperability and compatibility has to be kept and most mobile phones cannot be upgraded
2.5G: GPRS/EDGE Encryption Mobile TLC industry Operate at Layer2 (LLC) Does not have any relationship with A5/1 or A5/2 of GSM Algorithm used: GEA0 (no encryption) GEA1 (export controlled) GEA2 (normal strength) GEA3 (GPRS use of Kasumi)
3G: UMTS encryption Mobile TLC industry UMTS use two set of algorithms: UEA1 and UIA1, based on Kasumi UEA2 and UIA2, based on SNOW 3G In UMTS there is a mutual authentication between handset and the network In 2005 it has been demonstrated 1 st  an attack (yet not so practical) against KASUMI In 2010 it has been demonstrated the recovery of full key against Kasumi, but still not practical for how it’s used in 3G systems Have a look at http://eprint.iacr.org/2010/013
4G: LTE multiple encryption Mobile TLC industry LTE is a still a work-in-progress protocol It follow a completely different approach respect to 2G and 3G: Supporting a multiple set of conceptually different encryption algorithms to be able to resist against a single attack 128-EEA1 and 128-EIA1 (identical to UMTS UEA2 and UIA2 based on SNOW) 128-EEA2 and 128-EIA2 (based on AES) 128-EEA3 and 128-EIA3 (based on ZUC) Extend USIM key length up to 256-bit Mandatory Backhaul protection (BTS/BSC -> MSC) Mandatory TS 33.401 Security Architecture for LTE
UMA / GAN Mobile TLC industry Trough UMA (Unlimited Mobile Access) / GAN (Generic Access Network), roaming between 2G/3G and IP network UMA reuse as-is IETF available standards IPSEC with IKEv2 key exchange 3DES/AES encryption NAT-T IPSEC tunneling EAP-SIM for authentication with SIM EAP-AKA for authentication with USIM
Government and Military NATO / NSA
Intro Government always used to keep encryption algorithm and protocols secrets Multiple different communication protocol Multiple different security protocols Multiple different cryptographic suites Multiple different key management system Current multilateral context is changing Budget reduction and military cooperation lead to interoperability requirements Government and Military
SIGSALY Secure Voice System Circa 1943, SIGSALY provided perfect security for secure voice communication among allies.  Twelve units were built and deployed in Washington, London, Algiers, Brisbane , Paris ….. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
Sylvania’s ACP-0 (Advanced Computational Processor) Circa 1966, the ACP-0 was the first programmable digital signal processing computer.  A 12-bit machine, it was used to program modems, voice and error control coders. One unit was built, leading to the ACP-1, a 16-bit machine. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
Sylvania’s PSP (Programmable Signal Processor) Circa 1970, the PSP was Sylvania’s third generation programmable digital signal processing computer. A 16-bit machine.  The PSP led to the STU-I. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
STU-I Circa 1979, the STU-I used the PSP digital signal processing computer.  A few hundred units were eventually deployed. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
Original STU-II Circa 1982, the STU-II provided 2400 and 9600 bps secure voice.  A few thousand units were eventually deployed. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
First interoperability attempt US STU-II was first device set interoperable with NATO NBSV-II devices But in 1985 NSA initiated FSVS (Future Secure Voice System) and created in 1987 STU-III ISDN voice encryption Units Government and Military Selex BRENT BRENT And the story repeat again… broken interoperability with European NATO partners! German TopSec-703
But again in the ‘90 STE appeared! A new architecture for secure telecommunication for multi-media communication lines (Radio, ISDN, Satellite) STE works by completely avoiding internal crypto operations with KOV-14 Fortezza Plus Crypto Card Government and Military Since 2004  STE are currently the official voice encryption device of US, with firmware upgrade to support SCIP,  VoIP and for a variety of new Crypto Card: KSV-21 – Type 1 TOP Secret USA KSV-40 – NATO TOP Secret SSV-50 – Coalition Partners KSV-30 – CCEB (Australia, New Zealand, UK, US, Canada)
Finally standard telephony: FNBDT / SCIP In 1997 Future Narrow Band Digital Terminal (FNBDT) project is started in the US to create a multiple media and interoperable voice secure communication protocol Baton 320-bit NSA secret symmetric crypto algorithm Firefly key exchange for EKMS (standardized as Photuris RFC2522) In 2003 it has been proposed for use within NATO, with the creation of IICWG interworking group In 2004 it has been renamed to Secure Communication Interoperability Protocol (SCIP) AES for symmetric encryption Extended key exchange with Enhanced Firefly Government and Military
SCIP: Tech sheet Application layer secure telephony protocol (L7) Works over any media (Radio, GSM, ATM, ISDN, SATCOM) Use MELPe codec (600-2400bit/s) or G.729D (5300bit), royalty free only for US Government and NATO Allow the implementation of custom proprietary symmetric and asymmetric encryption system while keeping interoperability Example multi-vendor interoperable Voice infrastructure Government and Military
NSA EKMS The Electronic Key Management System of NSA has been adopted as a standard for the handling of key distribution and authentication EKMS is based on Enhanced Firefly (Photuris RFC specification) Periodic Re-keying is required by policy (OTAR) EKMS Is tier-based hierarchy… do you remember x509v3 PKI? :-) Government and Military
SCIP: Where are the specification? It’s the typical not-so-open but standard technology Googling tell you something about what to look for: FNBDT-120 – Key Management Plan FNBDT-230 Cryptographic Specification FNBDT-220 Conditions for interoperability SCIP-231 AES Encryption But no official public document other than…. Check  http://nc3a.info/MDS/FNBDT/FNBDT_NATO_BriefV9.ppt FNBDT Signaling schematics!!! Check  http://www.dtic.mil/dticasd/sbir/sbir041/srch/sbir147.html FNBDT 1999 partial initial specification document!!!!! Government and Military
SCIP protocol stack view Government and Military
Some SCIP Manufacturer US - NSA, General Dynamic, L3 Communications UK – QinetiQ, DSTL DE – BSI, R&S IT – SELEX FR – EADS, SAGEM, THALES ES – GS, Technobi RO – Electromagnetica TR – TUBITAK, ASSELSAN NATO – NHQC3S, NC3A Government and Military
Public Safety European ETSI standard for an interoperable world
From analog scrambler…. First encrypted radio was using unsecure voice frequency inversion (scrambling) RSA and Diffie-Hellman was born trying to create syncronization methods from scramblers Scramblers cannot be secure as they don’t do encryption Often referred scrambler are digitizer (modem) that over the digital path make encryption Scrambler has been cracked in a lot of countries with simple PC software Frequency Hopping Radio transmission techniques (TRANSEC) has been added to modern radio security techniques to increase security at layer1 Public Safety
To TETRA (1) Designed as ETSI standard Terrestrial Trunked Radio (but France has it’s own TETRAPOL variant) Used in +35 nations (not only europe but also Russia, India, Brazil, Argentina, etc) Operate on 400mhz on a different infrastructure 0.5s call setup Provide IP packet transport over tetra Operate without a network with Direct Mode Operations Each device is able to works as a independent repeater Public Safety
To TETRA (2) Signaling is encrypted Voice and Data are encrypted Similar to GSM with Ki private secret residing on SIM or on Trusted Mobile device Support for mutual authentication with the network Support point-to-point and point-to-multipoint end-to-end encryption Release: 1994 Formation of Tetra consortium 1999 Tetra Release 1 2005 Tetra Release 2 (+AMR +CELP +Extended DMO) Public Safety
TETRA encryption algorithms Tetra Authentication Key Management Algorithm: TAA1 Algorithm for encryption (secret codes): TEA1: 1 st  exportable Tetra algorithm (distributed by ETSI) TEA2: 1 s  strong encryption for schengen countries (distributed by Dutch Police IT Organization) TEA3: 2 nd  strong encryption for schengen countries (distributed by ETSI) TEA4: 2 nd  exportable Tetra algorithm (distributed by ETSI) Support end-to-end encryption with IDEA, AES and custom algorithms http://www.tetramou.com/uploadedFiles/Files/Documents/Overviewofstandardcryptographicalgorithms.pdf http://www.tetramou.com/uploadedFiles/About_TETRA/TETRA%2520Security%2520pdf.pdf Public Safety
TETRA encryption configuration Clear (no air interface encryption) without End to End Encryption TETRA Encryption Algorithm 1 (TEA1) without End to End Encryption TETRA Encryption Algorithm 2 (TEA2) without End to End Encryption TETRA Encryption Algorithm 3 (TEA3) without End to End Encryption Clear (no air interface encryption) with End to End Encryption TETRA Encryption Algorithm 1 (TEA1) with End to End Encryption TETRA Encryption Algorithm 2 (TEA2) with End to End Encryption TETRA Encryption Algorithm 3 (TEA3) with End to End Encryption Public Safety
TETRA BOS digital radio (germany) Example implementation by BSI of the German TETRA network with smartcard security https://www.bsi-fuer-buerger.de/cae/servlet/contentblob/487530/publicationFile/27989/BSI_AnnualReport2005_pdf Public Safety
IETF VoIP security standards
VoIP basic IETF VoIP standard apply to internet and IP based communications SIP is used to transport signaling information RTP is used to carry media traffic (audio, video) Both usually works over UDP protocol SIP can works securely across a TLS secured channel IETF VoIP security standards
Signaling Encryption: SIP/TLS Provide a secured and network authenticated channel for signaling with TLSv1 (much like HTTPS) IETF VoIP security standards
Media encryption: SRTP  SRTP describe how to encrypt and guarantee the integrity of RTP packets Encryption has been brought to IETF standard in March 2004 with SRTP (RFC3711) Several Key Exchange methods has been standardized SRTP support for symmetric encryption AES128 Counter mode AES128 f8-mode SRTP for integrity checking  HMAC-SHA1 32 bit version 80 bit version Upcoming internet-draft fo AES-192 and AES-256 IETF VoIP security standards
Media encryption: SRTP  IETF VoIP security standards
E2S Key exchange: SDES SDES is the only widely diffused and implemented key agreement method It’s transported over SIP channel protected with TLS IETF VoIP security standards
E2S Key exchange: SDES packet IETF VoIP security standards INVITE sips:* [email_address] ;user=phone SIP/2.0 Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport From: &quot;123&quot; <sips: [email_address] g >;tag=mogkx srhm4 To: <sips:* [email_address] ;user=phone> Call-ID: 3 [email_address] CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip: [email_address] :2049;transport=t ls;line =gyhiepdm> ;reg-id=1 User-Agent: snom360/6.2.2 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces, callerid Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 477 v=0 o=root 2071608643 2071608643 IN IP4 172.20.25.100 s=call c=IN IP4 172.20.25.100 t=0 0 m=audio 57676 RTP/AVP 0 8 9 2 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=encryption:optional a=sendrecv
E2E/E2S Key exchange: MIKEY Mikey has been standardized in 2004 as RFC3830 Provide a key exchange method for SRTP on the SIP channel via SDP attribute It has been updated with RFC4738 to support other exchange method Mikey support several key exchange method Null Pre-shared keys Diffie Hellman Diffie Hellman HMAC RSA RSA (reverse mode) Given the implementation complexity it never got really deployed IETF VoIP security standards
End-to-end encryption key exchange for SRTP As a story we all have already seen with OpenPGP/MIME vs. S/MIME there are two competing standards A Hierarchical standard to be integrated within PKI infrastructure - DTLS A non hierarchical standard with a very high level or paranoid feature - ZRTP IETF VoIP security standards
E2E key exchange - DTLS In March 2006 DTLS (Datagram Transport Layer Security) has been defined to protect UDP streams much like SSL and the successor TLS used in the web world RTP runs over UDP In 2008 a method to use DTLS as a key exchange method of SRTP to encipher RTP packets  won the standardization path of IETF IETF VoIP security standards
E2E Key Exchange: DTLS-SRTP Require a PKI to be used It completely rely on SIP channel integrity In order to keep the SIP channel integrity “Enhanced SIP identity” standard (RFC4475) has to be used . Unfortunately MiTM protection cannot be guaranteed when calling a phone number (+4179123456789) and so DTLS-SRTP collapse in providing security So the basic concept is that DTLS require a PKI to works, with all the burocracy and complexity around building it Most of the vendor that announced to use DTLS-SRTP said that they will provide self-signed certificate IETF VoIP security standards
E2E Key exchange: ZRTP (1) Mr. Zimmermann did it again and by leveraging the old PGPhone concept of 1995 he designed and proposed for standardization ZRTP VoIP security protocol ZRTP does not use SIP but instead use in a clever way the RTP packet to perform in-band (inside RTP) key handshake The concept is simple: what we need to protect? The media So why modify the SIP signaling increasing complexity? KISS principle always stay ahead  Implemented by Philip Zimmermann (zfoneproject.com), Werner Viettmann (gnutelephony.org), MT5 (unknown non-public implementation) IETF VoIP security standards
E2E Key exchange: ZRTP (2) ZRTP is provided to IETF as a standard (currently in standardization path) as a key initialization method for SRTP ZRTP use different key agreements method inside the  cryptographic protocol ECDH (NSA Suite B) DH Preshared Key ZRTP support PFS (Perfect Forward Secrecy) Self-healing key cache (avoid ssh-like attack) Can be used over most signaling protocols that use RTP for media transport (SIP, H.323, Jingle, P2P SIP) IETF VoIP security standards
E2E Key exchange: ZRTP (3) IETF VoIP security standards
ZRTP (4) Short Authentication String as a method to detect MiTM wiretapper the two users at the endpoints verbally compare a shared value displayed at both end If the value don’t match, it indicates the presence of someone doing a man in the middle attack IETF VoIP security standards
Comparison of key agreements method of SRTP IETF VoIP security standards Technology SDES SRTP - ZRTP SRTP - MIKEY SRTP - DTLS Require signaling security Yes No Depend Yes (with additional complexity) End-to-Site security Yes No Depend Yes End-to-End security No Yes Depend Yes (it depends) Man in the middle protection No Yes Yes Yes (not always) Different implementation in 2010 Yes Yes not widely diffused No
Various anti-wiretapping secure phone Misc solutions not fitting precisely in any category (private, business)
Too many technologies Various anti-wiretapping secure phone A lot of technologies Extremely fragmented market Companies often based on captive customer group 90% of case no details on custom crypto: Just trust the company! Mainly targeting enterprise and VIP sector
A bit of history: clipper, born to fail Clipper Chip was created by White House in 1993 implementing SkipJack algorithm In 1994 FIPS 185 Escrowed Encryption Standard has been approved AT&T release TD3600E 56bit encryption 4800bps data path over PSTN In 1996 the project was considered a complete failure In 1998 skipJack has been declassified Various anti-wiretapping secure phone
A bit of history: PGPhone In 1995 mr. Philip Zimmermann (2 ‘n) created PGPhone PGPhone was a software for Windows to be used connecting the PC trough a modem an dialing the other party Was using ephemeral Diffie-Hellmann protocol Was using a short authentication string to detect man in the middle attack Unfortunately he was too visionary, in 1996 the internet world was still not ready for such technology In 1997 it became abandon-ware Various anti-wiretapping secure phone
A bit of history: Cryptophone In 2001 Cryptophone was born and it kept fully open their source code and security protocol design The company (composed of several very good hackers) build up the product and started selling the hardware phones Unfortunately the protocol did not get public attention (also because of lack of independent separated specification/implementation) and did not get strong public auditing nor other interoperable use Now works on CSD and IP No IP specs has been released Various anti-wiretapping secure phone
ZRTP for CS telephony and Radio ZRTP/S In 2008 Mr. Zimmermann developed jointly with KHAMSA (now PrivateWave) an extension of ZRTP to works again, like PGPhone already does in 1995, over traditional phone lines Resulting product is PrivateGSM CSD (Nokia) ZRTP/S is a communication and security protocol that works over traditional telephony technologies (GSM, UMTS, CDMA IS94a, PSTN, ISDN, SATCOM, BLUETOOTH) Basically it works over a ‘bitstream channel’ that can be easily represented like a ‘serial connection’ between two devices Various anti-wiretapping secure phone
ZRTP/S Tech sheet ZRTP/S can be, oversimplifying, a subset of a “compatible” RTP packet refactored to works over narrowband channels It works over very narrowband links (4800 - 9600bps) It works over high latency links (GSM CSD and SAT) with a “compressed” ZRTP handshake In order to works over most channel it require the usage of narrowband audio codecs with advanced DTX and CNG features (AMR 4.75, Speex 3.95, MELPe 2.4) Implemented in open source as additional module to libzrtp Soon to be released for public and community usage Various anti-wiretapping secure phone
Chocolate grade encryption? IMHO most of the remaining systems fit into the category of chocolate grade encryption Just say “We use AES” or “We use DH key exchange” No detailed encryption protocol specs No public review Claim “military-grade” and “unbreakable” Often claim incredible bit size like 16000 bit authentication or 46080 bit encryption Typically no support for PFS Typically vulnerable to local key compromise No, i will not refer to any name here Various anti-wiretapping secure phone
PIN to protect local keys? Wrong! Example of chocolate grade encryption is with digital certificate system based on user security PIN. You used the best asymmetric crypto You used the best symmetric crypto You designed a complex and full featured enterprise key management system (x509v3) But  on mobile device no secure passphrase is possible  for frequent use by users Poor keyboard  Poor Password As a result the overall security model is strong as much as the PIN strength used to unlock the application that protect the private key Various anti-wiretapping secure phone Type a passphrase here: Pa;!sd83/1@sZ
Conclusion
To summarize Different technologies for different markets and use Market and technologies are fragmented The race to standardization will fire all non standard technologies Most standard technologies include support for proprietary extensions for crypto All standards (TLC, Government, Public Safety and IETF) must be open and not restricted to a wallet garden because of the risk that the history of GSM A5/1 repeat again Conclusion
Major Voice Security protocol Review Voice Security Protocol Review An overview of all major voice security protocols like never done Fabio Pietrosanti (naif) Email:  [email_address] Blog:  http://infosecurity.ch

Voice securityprotocol review

  • 1.
    Major Voice Securityprotocol Review Voice Security Protocol Review An overview of all major voice security protocols like never done Fabio Pietrosanti (naif) Email: [email_address] Blog: http://infosecurity.ch
  • 2.
    Agenda: Mission impossiblein 1 hour? 1 – Understanding voice encryption 2 – Mobile TLC industry standards 3 - Government and Military standards 4 - Public Safety standards 5 - IETF VoIP Security standards 6 - Various anti-wiretapping secure phones 7 - Conclusion From this talk you will learn a lot about: Different requirements among voice encryption technologies Major voice encryption standards
  • 3.
    Who am iFabio Pietrosanti Works in IT Sec till ’98 Stay in digital underground with nickname “naif” till ’95 Worked as network security manager for I.NET SpA, Security Advisor Corporate Security Telecom Italia Now CTO of KHAMSA ITALIA SPA doing voice encryption stuff http://www.privatewave.com Project and engineer strong encryption products and technologies for VOICE Technology partnership with Philip Zimmermann Participate to underground communities, sikurezza.org, s0ftpj, metro olografix, progetto winston smith, etc
  • 4.
    Being founder andCTO of a company doing voice encryption this presentation follow my view on encryption and security/wiretapping technologies My personal and professional feeling are about voice crypto are philosophically near to openness, standardization open-source, open and transparent peer review and i hate every closed and proprietary solution This presentation try to be as much as objective as possible
  • 5.
    5 Overview ofvoice encryption systems
  • 6.
    Communication technologies Traditionaltelephony (circuit switched) ISDN (fixed) PSTN (fixed) GSM/CDMA/UMTS (mobile) SAT (iridium, turaya, inmarsat, etc) VoIP Telephony (packet switched) Softphone on PC Hardware phones Mobile internet (GPRS, EV-DO, EVDO, etc) Radio transmission HF, UHF, EHF, VLF (air, space, earth, sea) Understanding voice encryption
  • 7.
    Authorities for standardsISO ITU-T GSM Consortium 3GPP 3GPP2 NSA NATO IETF Telecom Industry Association (US interim standards) Understanding voice encryption
  • 8.
    Result of complexityin technologies and authorities NO single standard for telephony NO single standard for security (not even enough!) And most persons just think that only Internet exists…! Understanding voice encryption
  • 9.
    Digital vs. AnalogScrambling Vs. Encryption Analog connection Vs. Digital connection Creating a digital data path over the media And what about the signaling? Outband signaling Inband signaling Best review of scrambling technologies with security evaluation: https://upcommons.upc.edu/pfc/bitstream/2099.1/4858/1/MarkusBrandau.pdf Understanding voice encryption
  • 10.
    TLC Communication technologiesBut bear in mind military and public safety requirement: Radio from ELF (3-3000hz) to EHF (30-300ghz) Understanding voice encryption Data Transmission Circuit Switched Packet Switched ISDN, GSM,CDMA,UMTS, PSTN, SAT VoIP Quality of service Granted GPRS / EDGE / UMTS Not Granted Coverage Full Only Urban Area Billing Per-second (sender pay) Per-packet (sender/receiver pay) Signaling Outband In-band (over IP)
  • 11.
    Different use caseand requirements Government (embassies and agencies) and Military (battlefield, earth, air, sea) Public safety Mobile Telecommunication industry IETF standards Misc use anti-wiretapping secure phone Understanding voice encryption
  • 12.
    Major technology summaryUnderstanding voice encryption Use case Technology End-To-Site Security End-to-En Security Government and Military SCIP Yes Yes Public Safety TETRA Yes Yes (optional) Mobile Industry GSM UMTS LTE Yes No IETF (Internet) SRTP/SDES SRTP/ZRTP Yes Yes
  • 13.
    Different security modelEnd-to-end Security point-to-point point-to-multipoint End-to-site Mixed setup Understanding voice encryption
  • 14.
    Security of cryptooperation Tamper proof encryption key container (SIM Card) Tamper proof enciphering hardware (NSA / NATO Crypto Card) Embedded hw/sw encryption along with tlc equipment General Trusted operating system General operating system Embedded custom (firmware) operating system False sense of security using old concepts Jtag debugging & reversing are currently diffused Firmware can be broken if not protected with trusted hardware Understanding voice encryption
  • 15.
    Standards vs ProprietaryMoving from a cold-war to multilateral operations bring to standardization and interoperability requirements Proprietary technology Require gateway for interoperability breaking end-to-end security Increase delay High costs Single vendor dependency Standards and open technologies Standards but closed technologies Standards but partially closed technologies Understanding voice encryption
  • 16.
    NSA Cryptographic ModernizationProgram Moving from proprietary to standard solution Interoperate with NATO and coalition Replacing 1.3milion encryption units in 10 years Avoid dependency on single vendor Reduce costs Update all equipments to modular crypto systems Not anymore single crypto system but modular upgradable systems Understanding voice encryption
  • 17.
    The race tostandardization Mobile TLC industry: GSM 2G: A5/1 , A5/2, A5/3 GPRS 2.5G: GEA1, GEA2, GEA3 UMTS 3G: UEA1, UEA2 UMA/GAN: IPSEC with IKEv2 / AES LTE 4G: 128-EEA1, 128-EEA2, 128-EEA3 Government and Military: SCIP / FBNDT Public safety: TETRA IETF Standard: SIP/RTP (SRTP -> SDES / ZRTP / DTLS) Secure Phone: Still plenty of various proprietary solution Understanding voice encryption
  • 18.
    Beware of SnakeOil Crypto Staying careful about snake oil encryption Bruce Schneier and Phil Zimmermann reference Snake Oil Encryption is Secret Algorithm Algorithm without key exchange details Security Expert review and useless certificates Unbreakable Unsubstantiated bit claims Not explaining the security model (end-to-end vs end-to-site) http://en.wikipedia.org/wiki/Snake_oil_(cryptography ) http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Understanding voice encryption
  • 19.
    Mobile TLC IndustryGSMA / 3GPP / LTE
  • 20.
    Security by lobbyingand patenting Mobile TLC industry TLC industry is represented mainly by large corporation Each standard is defined inside defined organization with the direct industry participation Standards are specifically defined in a cryptic and complex document formats Standards in mobile environment are very often plenty of patented methodologies Even if we refer always to “GSM” there are a lot of GSM releases Information is fragmented and the “Algorithm” custodian concept prevent immediate use for research http://gsmworld.com/our-work/programmes-and-initiatives/fraud-and-security/gsm_security_algorithms.htm
  • 21.
    2G: GSM encryptionMobile TLC industry Operate at Layer1 Provide one-way mobile to network authentication Provide mobile-to-BTS encryption A wide set of algorithms A5/0 (no encryption) A5/1 (standard encryption) A5/2 (export version, weak) A5/3 (Use of Kasumi in GSM) Given the peculiarity of the overall protocol all GSM communication can be broken, even with an upgrade to A5/3, because interoperability and compatibility has to be kept and most mobile phones cannot be upgraded
  • 22.
    2.5G: GPRS/EDGE EncryptionMobile TLC industry Operate at Layer2 (LLC) Does not have any relationship with A5/1 or A5/2 of GSM Algorithm used: GEA0 (no encryption) GEA1 (export controlled) GEA2 (normal strength) GEA3 (GPRS use of Kasumi)
  • 23.
    3G: UMTS encryptionMobile TLC industry UMTS use two set of algorithms: UEA1 and UIA1, based on Kasumi UEA2 and UIA2, based on SNOW 3G In UMTS there is a mutual authentication between handset and the network In 2005 it has been demonstrated 1 st an attack (yet not so practical) against KASUMI In 2010 it has been demonstrated the recovery of full key against Kasumi, but still not practical for how it’s used in 3G systems Have a look at http://eprint.iacr.org/2010/013
  • 24.
    4G: LTE multipleencryption Mobile TLC industry LTE is a still a work-in-progress protocol It follow a completely different approach respect to 2G and 3G: Supporting a multiple set of conceptually different encryption algorithms to be able to resist against a single attack 128-EEA1 and 128-EIA1 (identical to UMTS UEA2 and UIA2 based on SNOW) 128-EEA2 and 128-EIA2 (based on AES) 128-EEA3 and 128-EIA3 (based on ZUC) Extend USIM key length up to 256-bit Mandatory Backhaul protection (BTS/BSC -> MSC) Mandatory TS 33.401 Security Architecture for LTE
  • 25.
    UMA / GANMobile TLC industry Trough UMA (Unlimited Mobile Access) / GAN (Generic Access Network), roaming between 2G/3G and IP network UMA reuse as-is IETF available standards IPSEC with IKEv2 key exchange 3DES/AES encryption NAT-T IPSEC tunneling EAP-SIM for authentication with SIM EAP-AKA for authentication with USIM
  • 26.
  • 27.
    Intro Government alwaysused to keep encryption algorithm and protocols secrets Multiple different communication protocol Multiple different security protocols Multiple different cryptographic suites Multiple different key management system Current multilateral context is changing Budget reduction and military cooperation lead to interoperability requirements Government and Military
  • 28.
    SIGSALY Secure VoiceSystem Circa 1943, SIGSALY provided perfect security for secure voice communication among allies. Twelve units were built and deployed in Washington, London, Algiers, Brisbane , Paris ….. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
  • 29.
    Sylvania’s ACP-0 (AdvancedComputational Processor) Circa 1966, the ACP-0 was the first programmable digital signal processing computer. A 12-bit machine, it was used to program modems, voice and error control coders. One unit was built, leading to the ACP-1, a 16-bit machine. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
  • 30.
    Sylvania’s PSP (ProgrammableSignal Processor) Circa 1970, the PSP was Sylvania’s third generation programmable digital signal processing computer. A 16-bit machine. The PSP led to the STU-I. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
  • 31.
    STU-I Circa 1979,the STU-I used the PSP digital signal processing computer. A few hundred units were eventually deployed. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
  • 32.
    Original STU-II Circa1982, the STU-II provided 2400 and 9600 bps secure voice. A few thousand units were eventually deployed. Reference: SCIP, Objective, History and Future Development: Veselin Tselkov Government and Military
  • 33.
    First interoperability attemptUS STU-II was first device set interoperable with NATO NBSV-II devices But in 1985 NSA initiated FSVS (Future Secure Voice System) and created in 1987 STU-III ISDN voice encryption Units Government and Military Selex BRENT BRENT And the story repeat again… broken interoperability with European NATO partners! German TopSec-703
  • 34.
    But again inthe ‘90 STE appeared! A new architecture for secure telecommunication for multi-media communication lines (Radio, ISDN, Satellite) STE works by completely avoiding internal crypto operations with KOV-14 Fortezza Plus Crypto Card Government and Military Since 2004 STE are currently the official voice encryption device of US, with firmware upgrade to support SCIP, VoIP and for a variety of new Crypto Card: KSV-21 – Type 1 TOP Secret USA KSV-40 – NATO TOP Secret SSV-50 – Coalition Partners KSV-30 – CCEB (Australia, New Zealand, UK, US, Canada)
  • 35.
    Finally standard telephony:FNBDT / SCIP In 1997 Future Narrow Band Digital Terminal (FNBDT) project is started in the US to create a multiple media and interoperable voice secure communication protocol Baton 320-bit NSA secret symmetric crypto algorithm Firefly key exchange for EKMS (standardized as Photuris RFC2522) In 2003 it has been proposed for use within NATO, with the creation of IICWG interworking group In 2004 it has been renamed to Secure Communication Interoperability Protocol (SCIP) AES for symmetric encryption Extended key exchange with Enhanced Firefly Government and Military
  • 36.
    SCIP: Tech sheetApplication layer secure telephony protocol (L7) Works over any media (Radio, GSM, ATM, ISDN, SATCOM) Use MELPe codec (600-2400bit/s) or G.729D (5300bit), royalty free only for US Government and NATO Allow the implementation of custom proprietary symmetric and asymmetric encryption system while keeping interoperability Example multi-vendor interoperable Voice infrastructure Government and Military
  • 37.
    NSA EKMS TheElectronic Key Management System of NSA has been adopted as a standard for the handling of key distribution and authentication EKMS is based on Enhanced Firefly (Photuris RFC specification) Periodic Re-keying is required by policy (OTAR) EKMS Is tier-based hierarchy… do you remember x509v3 PKI? :-) Government and Military
  • 38.
    SCIP: Where arethe specification? It’s the typical not-so-open but standard technology Googling tell you something about what to look for: FNBDT-120 – Key Management Plan FNBDT-230 Cryptographic Specification FNBDT-220 Conditions for interoperability SCIP-231 AES Encryption But no official public document other than…. Check http://nc3a.info/MDS/FNBDT/FNBDT_NATO_BriefV9.ppt FNBDT Signaling schematics!!! Check http://www.dtic.mil/dticasd/sbir/sbir041/srch/sbir147.html FNBDT 1999 partial initial specification document!!!!! Government and Military
  • 39.
    SCIP protocol stackview Government and Military
  • 40.
    Some SCIP ManufacturerUS - NSA, General Dynamic, L3 Communications UK – QinetiQ, DSTL DE – BSI, R&S IT – SELEX FR – EADS, SAGEM, THALES ES – GS, Technobi RO – Electromagnetica TR – TUBITAK, ASSELSAN NATO – NHQC3S, NC3A Government and Military
  • 41.
    Public Safety EuropeanETSI standard for an interoperable world
  • 42.
    From analog scrambler….First encrypted radio was using unsecure voice frequency inversion (scrambling) RSA and Diffie-Hellman was born trying to create syncronization methods from scramblers Scramblers cannot be secure as they don’t do encryption Often referred scrambler are digitizer (modem) that over the digital path make encryption Scrambler has been cracked in a lot of countries with simple PC software Frequency Hopping Radio transmission techniques (TRANSEC) has been added to modern radio security techniques to increase security at layer1 Public Safety
  • 43.
    To TETRA (1)Designed as ETSI standard Terrestrial Trunked Radio (but France has it’s own TETRAPOL variant) Used in +35 nations (not only europe but also Russia, India, Brazil, Argentina, etc) Operate on 400mhz on a different infrastructure 0.5s call setup Provide IP packet transport over tetra Operate without a network with Direct Mode Operations Each device is able to works as a independent repeater Public Safety
  • 44.
    To TETRA (2)Signaling is encrypted Voice and Data are encrypted Similar to GSM with Ki private secret residing on SIM or on Trusted Mobile device Support for mutual authentication with the network Support point-to-point and point-to-multipoint end-to-end encryption Release: 1994 Formation of Tetra consortium 1999 Tetra Release 1 2005 Tetra Release 2 (+AMR +CELP +Extended DMO) Public Safety
  • 45.
    TETRA encryption algorithmsTetra Authentication Key Management Algorithm: TAA1 Algorithm for encryption (secret codes): TEA1: 1 st exportable Tetra algorithm (distributed by ETSI) TEA2: 1 s strong encryption for schengen countries (distributed by Dutch Police IT Organization) TEA3: 2 nd strong encryption for schengen countries (distributed by ETSI) TEA4: 2 nd exportable Tetra algorithm (distributed by ETSI) Support end-to-end encryption with IDEA, AES and custom algorithms http://www.tetramou.com/uploadedFiles/Files/Documents/Overviewofstandardcryptographicalgorithms.pdf http://www.tetramou.com/uploadedFiles/About_TETRA/TETRA%2520Security%2520pdf.pdf Public Safety
  • 46.
    TETRA encryption configurationClear (no air interface encryption) without End to End Encryption TETRA Encryption Algorithm 1 (TEA1) without End to End Encryption TETRA Encryption Algorithm 2 (TEA2) without End to End Encryption TETRA Encryption Algorithm 3 (TEA3) without End to End Encryption Clear (no air interface encryption) with End to End Encryption TETRA Encryption Algorithm 1 (TEA1) with End to End Encryption TETRA Encryption Algorithm 2 (TEA2) with End to End Encryption TETRA Encryption Algorithm 3 (TEA3) with End to End Encryption Public Safety
  • 47.
    TETRA BOS digitalradio (germany) Example implementation by BSI of the German TETRA network with smartcard security https://www.bsi-fuer-buerger.de/cae/servlet/contentblob/487530/publicationFile/27989/BSI_AnnualReport2005_pdf Public Safety
  • 48.
  • 49.
    VoIP basic IETFVoIP standard apply to internet and IP based communications SIP is used to transport signaling information RTP is used to carry media traffic (audio, video) Both usually works over UDP protocol SIP can works securely across a TLS secured channel IETF VoIP security standards
  • 50.
    Signaling Encryption: SIP/TLSProvide a secured and network authenticated channel for signaling with TLSv1 (much like HTTPS) IETF VoIP security standards
  • 51.
    Media encryption: SRTP SRTP describe how to encrypt and guarantee the integrity of RTP packets Encryption has been brought to IETF standard in March 2004 with SRTP (RFC3711) Several Key Exchange methods has been standardized SRTP support for symmetric encryption AES128 Counter mode AES128 f8-mode SRTP for integrity checking HMAC-SHA1 32 bit version 80 bit version Upcoming internet-draft fo AES-192 and AES-256 IETF VoIP security standards
  • 52.
    Media encryption: SRTP IETF VoIP security standards
  • 53.
    E2S Key exchange:SDES SDES is the only widely diffused and implemented key agreement method It’s transported over SIP channel protected with TLS IETF VoIP security standards
  • 54.
    E2S Key exchange:SDES packet IETF VoIP security standards INVITE sips:* [email_address] ;user=phone SIP/2.0 Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport From: &quot;123&quot; <sips: [email_address] g >;tag=mogkx srhm4 To: <sips:* [email_address] ;user=phone> Call-ID: 3 [email_address] CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip: [email_address] :2049;transport=t ls;line =gyhiepdm> ;reg-id=1 User-Agent: snom360/6.2.2 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces, callerid Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 477 v=0 o=root 2071608643 2071608643 IN IP4 172.20.25.100 s=call c=IN IP4 172.20.25.100 t=0 0 m=audio 57676 RTP/AVP 0 8 9 2 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=encryption:optional a=sendrecv
  • 55.
    E2E/E2S Key exchange:MIKEY Mikey has been standardized in 2004 as RFC3830 Provide a key exchange method for SRTP on the SIP channel via SDP attribute It has been updated with RFC4738 to support other exchange method Mikey support several key exchange method Null Pre-shared keys Diffie Hellman Diffie Hellman HMAC RSA RSA (reverse mode) Given the implementation complexity it never got really deployed IETF VoIP security standards
  • 56.
    End-to-end encryption keyexchange for SRTP As a story we all have already seen with OpenPGP/MIME vs. S/MIME there are two competing standards A Hierarchical standard to be integrated within PKI infrastructure - DTLS A non hierarchical standard with a very high level or paranoid feature - ZRTP IETF VoIP security standards
  • 57.
    E2E key exchange- DTLS In March 2006 DTLS (Datagram Transport Layer Security) has been defined to protect UDP streams much like SSL and the successor TLS used in the web world RTP runs over UDP In 2008 a method to use DTLS as a key exchange method of SRTP to encipher RTP packets won the standardization path of IETF IETF VoIP security standards
  • 58.
    E2E Key Exchange:DTLS-SRTP Require a PKI to be used It completely rely on SIP channel integrity In order to keep the SIP channel integrity “Enhanced SIP identity” standard (RFC4475) has to be used . Unfortunately MiTM protection cannot be guaranteed when calling a phone number (+4179123456789) and so DTLS-SRTP collapse in providing security So the basic concept is that DTLS require a PKI to works, with all the burocracy and complexity around building it Most of the vendor that announced to use DTLS-SRTP said that they will provide self-signed certificate IETF VoIP security standards
  • 59.
    E2E Key exchange:ZRTP (1) Mr. Zimmermann did it again and by leveraging the old PGPhone concept of 1995 he designed and proposed for standardization ZRTP VoIP security protocol ZRTP does not use SIP but instead use in a clever way the RTP packet to perform in-band (inside RTP) key handshake The concept is simple: what we need to protect? The media So why modify the SIP signaling increasing complexity? KISS principle always stay ahead Implemented by Philip Zimmermann (zfoneproject.com), Werner Viettmann (gnutelephony.org), MT5 (unknown non-public implementation) IETF VoIP security standards
  • 60.
    E2E Key exchange:ZRTP (2) ZRTP is provided to IETF as a standard (currently in standardization path) as a key initialization method for SRTP ZRTP use different key agreements method inside the cryptographic protocol ECDH (NSA Suite B) DH Preshared Key ZRTP support PFS (Perfect Forward Secrecy) Self-healing key cache (avoid ssh-like attack) Can be used over most signaling protocols that use RTP for media transport (SIP, H.323, Jingle, P2P SIP) IETF VoIP security standards
  • 61.
    E2E Key exchange:ZRTP (3) IETF VoIP security standards
  • 62.
    ZRTP (4) ShortAuthentication String as a method to detect MiTM wiretapper the two users at the endpoints verbally compare a shared value displayed at both end If the value don’t match, it indicates the presence of someone doing a man in the middle attack IETF VoIP security standards
  • 63.
    Comparison of keyagreements method of SRTP IETF VoIP security standards Technology SDES SRTP - ZRTP SRTP - MIKEY SRTP - DTLS Require signaling security Yes No Depend Yes (with additional complexity) End-to-Site security Yes No Depend Yes End-to-End security No Yes Depend Yes (it depends) Man in the middle protection No Yes Yes Yes (not always) Different implementation in 2010 Yes Yes not widely diffused No
  • 64.
    Various anti-wiretapping securephone Misc solutions not fitting precisely in any category (private, business)
  • 65.
    Too many technologiesVarious anti-wiretapping secure phone A lot of technologies Extremely fragmented market Companies often based on captive customer group 90% of case no details on custom crypto: Just trust the company! Mainly targeting enterprise and VIP sector
  • 66.
    A bit ofhistory: clipper, born to fail Clipper Chip was created by White House in 1993 implementing SkipJack algorithm In 1994 FIPS 185 Escrowed Encryption Standard has been approved AT&T release TD3600E 56bit encryption 4800bps data path over PSTN In 1996 the project was considered a complete failure In 1998 skipJack has been declassified Various anti-wiretapping secure phone
  • 67.
    A bit ofhistory: PGPhone In 1995 mr. Philip Zimmermann (2 ‘n) created PGPhone PGPhone was a software for Windows to be used connecting the PC trough a modem an dialing the other party Was using ephemeral Diffie-Hellmann protocol Was using a short authentication string to detect man in the middle attack Unfortunately he was too visionary, in 1996 the internet world was still not ready for such technology In 1997 it became abandon-ware Various anti-wiretapping secure phone
  • 68.
    A bit ofhistory: Cryptophone In 2001 Cryptophone was born and it kept fully open their source code and security protocol design The company (composed of several very good hackers) build up the product and started selling the hardware phones Unfortunately the protocol did not get public attention (also because of lack of independent separated specification/implementation) and did not get strong public auditing nor other interoperable use Now works on CSD and IP No IP specs has been released Various anti-wiretapping secure phone
  • 69.
    ZRTP for CStelephony and Radio ZRTP/S In 2008 Mr. Zimmermann developed jointly with KHAMSA (now PrivateWave) an extension of ZRTP to works again, like PGPhone already does in 1995, over traditional phone lines Resulting product is PrivateGSM CSD (Nokia) ZRTP/S is a communication and security protocol that works over traditional telephony technologies (GSM, UMTS, CDMA IS94a, PSTN, ISDN, SATCOM, BLUETOOTH) Basically it works over a ‘bitstream channel’ that can be easily represented like a ‘serial connection’ between two devices Various anti-wiretapping secure phone
  • 70.
    ZRTP/S Tech sheetZRTP/S can be, oversimplifying, a subset of a “compatible” RTP packet refactored to works over narrowband channels It works over very narrowband links (4800 - 9600bps) It works over high latency links (GSM CSD and SAT) with a “compressed” ZRTP handshake In order to works over most channel it require the usage of narrowband audio codecs with advanced DTX and CNG features (AMR 4.75, Speex 3.95, MELPe 2.4) Implemented in open source as additional module to libzrtp Soon to be released for public and community usage Various anti-wiretapping secure phone
  • 71.
    Chocolate grade encryption?IMHO most of the remaining systems fit into the category of chocolate grade encryption Just say “We use AES” or “We use DH key exchange” No detailed encryption protocol specs No public review Claim “military-grade” and “unbreakable” Often claim incredible bit size like 16000 bit authentication or 46080 bit encryption Typically no support for PFS Typically vulnerable to local key compromise No, i will not refer to any name here Various anti-wiretapping secure phone
  • 72.
    PIN to protectlocal keys? Wrong! Example of chocolate grade encryption is with digital certificate system based on user security PIN. You used the best asymmetric crypto You used the best symmetric crypto You designed a complex and full featured enterprise key management system (x509v3) But on mobile device no secure passphrase is possible for frequent use by users Poor keyboard Poor Password As a result the overall security model is strong as much as the PIN strength used to unlock the application that protect the private key Various anti-wiretapping secure phone Type a passphrase here: Pa;!sd83/1@sZ
  • 73.
  • 74.
    To summarize Differenttechnologies for different markets and use Market and technologies are fragmented The race to standardization will fire all non standard technologies Most standard technologies include support for proprietary extensions for crypto All standards (TLC, Government, Public Safety and IETF) must be open and not restricted to a wallet garden because of the risk that the history of GSM A5/1 repeat again Conclusion
  • 75.
    Major Voice Securityprotocol Review Voice Security Protocol Review An overview of all major voice security protocols like never done Fabio Pietrosanti (naif) Email: [email_address] Blog: http://infosecurity.ch

Editor's Notes

  • #26 http://gsmsecurity.blogspot.com/2009/05/a53-or-kasumi-encryption.html