Is it the end of October already? As has been true for centuries, there is a tradition for children to wear costumes and disguise themselves while going door to door with a simple question: “Trick or treat?” While I am not sure there is a coincidence, but having National Cyber Security Awareness Month (NCSAM) end on a day characterized by pranks, false identifications and the like seems appropriate. And what scary stories we had to tell!
Cryptography is critical to secure, trustworthy communications. Recent questions within the tech industry have created entirely new discussions about the cryptography underpinning our communications infrastructure. While some in the media have focused on the algorithm chosen for Deterministic Random Bit Generation (DRBG), we’ve seen many more look to have a broader crypto conversation. With this backdrop, I’d like to take the opportunity to talk about how we select algorithms (not just the DRBGs) for our products.
Before we go further, I’ll go ahead and get it out there: we don’t use the DUAL_EC_DRBG in our products. While it is true that some of the libraries in our products can support the DUAL_EC_DRBG, it is not invoked in our products. For our developers, the DRBG selection is driven by an internal standard and delivered to those developers from an internal team of crypto experts through a standard crypto library. The DRBG algorithm choice cannot be changed by the customer. Our Product Security Incident Response Team (PSIRT) confirmed this in a Security Response published on October 16.
In order for government and enterprise organizations to keep their data secure from increasingly advanced cyber threats, security solutions and protocols are critical. However, these organizations must ensure that their chosen security solutions meet key security criteria, are standards based, perform as expected and interoperate reliably with existing technology.
The challenges above are why Common Criteria was created. Common Criteria is an international standard for IT product security and reliability. In fact, many governments will not use security products that don’t meet Common Criteria standards.
This year, the International Common Criteria Conference is being held in Orlando, Florida from September 10-12. The conference is a place for Certification Bodies, Evaluation Laboratories, Researchers, Evaluators, Product Makers and Buyers and Sellers to come together and exchange ideas in order to improve Common Criteria.
Cisco will lead multiple sessions covering topics like Cryptography, Network Device Protection Profiles, Improving Common Criteria and Marketing Common Criteria.
Details on the speaking sessions presented by and in collaboration with Cisco are below:
- Keynote Speaker: CCUF Perspective
September 11 from 9-9:30AM ET
Alicia Squires, Cisco, CCUF Chair
- Marketing the New CC
September 11 from 9:30-11AM ET
Moderator: Mark Loepker, NIAP, CCES Chair
Panelists: Joshua Brickman, Oracle; Jen Gilbert, Cisco; Matt Keller, Corsec; Eric Winterton, Booz Allen Hamilton.
- Entropy Sources -- Industry Realities and Evaluation Challenges
September 11 from 10-10:30AM ET
Alicia Squires: CISSP, Product Certification Engineer, Cisco Chair, CCUF Management Group
- Cryptography and Common Criteria
September 11 from 11:30-12PM ET
Ashit Vora, Manager, Common Criteria Certification, Cisco and Chris Brych, Manager, Security Certifications, SafeNet, Inc.
- Lessons and Recommendations from Evaluating Against NDPP in Three Different Schemes
September 11 from 5-5:30PM ET
Terrie Diaz, Product Certification Engineer, Cisco and Ashit Vora, Manager, Common Criteria Certification, Cisco
- Widening the Use of CC for End Users Worldwide
September 12 from 9:30-11AM ET
Moderator: Michele Mullen, Director, ATA, CSEC
Adam Golodner, Director, Global Security & Technology Policy, Cisco; Steve Lipner, Microsoft; Blackberry (INVITED); Ericsson (INVITED)
Some of the best conversations happen in private exchanges and I often wish we could all benefit more broadly. This most recent conversation was instructive in and of itself but it also pointed out a level of transparency both Jimmy Ray and I prefer. So hopefully it goes to say -- we welcome your input! We certainly don’t get it right all the time!
Episode 119 featured Next Generation encryption and we mistakenly attributed Great Britain with breaking Enigma. One of our Cisco fans from Warsaw, Bartlomiej (Bartek) Michalowski, sent us a note.
Over the years, numerous cryptographic algorithms have been developed and used in many different protocols and functions. Cryptography is by no means static. Steady advances in computing and in the science of cryptanalysis have made it necessary to continually adopt newer, stronger algorithms, and larger key sizes. Older algorithms are supported in current products to ensure backward compatibility and interoperability. However, some older algorithms and key sizes no longer provide adequate protection from modern threats and should be replaced.
Over the years, some cryptographic algorithms have been deprecated, “broken,” attacked, or proven to be insecure. There have been research publications that compromise or affect the perceived security of almost all algorithms by using reduced step attacks or others (known plaintext, bit flip, and more). Additionally, every year advances in computing reduce the cost of information processing and data storage to retain effective security. Because of Moore’s law, and a similar empirical law for storage costs, symmetric cryptographic keys must grow by 1 bit every 18 months. For an encryption system to have a useful shelf life and securely interoperate with other devices throughout its life span, the system should provide security for 10 or more years into the future. The use of good cryptography is more important now than ever before because of the very real threat of well-funded and knowledgeable attackers.
Next Generation Encryption (NGE) technologies satisfy the security requirements described above while using cryptographic algorithms that scale better. For more information on Legacy, Acceptable, Recommended and NGE algorithms that should be avoided or used in your networks, you can refer to our latest Whitepaper.