How fortunate I’ve been, to not have had a weekend job in basically my whole life. I worked night fill in my teens, which is a weeknights thing, I tutored university to get through undergrad, and while the jobs I had between undergrad and ending the Ada Initiative were all varying degrees of soft money, they were all weekday jobs, aside from the travel. And even work travel involves weekends where I can lie in a hotel room eating sashimi and trying not to be too sick from jetlag. (Protein, fat, and sheer misery: the bitter diet of the jetsetting class.)
February was the last month without working weekends for a while to come. But they were still parenting weekends, with V having both athletics and swimming on Saturdays. We made a one night trip to see my parents before the end of summer, which was worth it, but the eight hours of driving in two days hurt. Last days in the pool, lots of threatening clouds and not a lot of rain.
March was the brief interregnum between hauling everyone down to King George Oval for athletics on Saturday morning and hauling everyone down to Callan Park Oval for soccer on Saturday morning. Just swimming lessons on Saturdays, luxury. We had Sam and Hannah over for dinner in one of our rare and always nice uses of our outdoor furniture, and we went around to Mark and Tim’s so that V could turn up his nose at all their child-friendly food, but I also kicked off my weekend work for the first time. Rather gently so; I did a secondary oncall, for which I need to be half an hour away from starting work at all times, not primary oncall (five minutes from beginning work). It wasn’t until April that a real trial by oncall fire kicked in at work. Perhaps gentle March is what I should aim to return to sometime soon.
Gutenberg's original printing press was based on a wine press - who knew? If you think beer or wine is dangerous, you may think the best thing to do is prohibit alcohol. In 1919, the Womens Christian Temperance Union requested that the public library to remove books and pamplets on the home production of alcohol for drinks. the librarians would not destroy the books, but did remove them from public access.
Why do censors try to ban instructions? "It might be bad if people follow these instructions" - stop people from acting on information. We have freedom of speech, though, so we shouldn't accept this. You can try to hide the information, but they will still find it and figure it out. Censorship adds very little benefit, and often causes massive damage.
There are careful exceptions to free speech in the US- you cannot intentionally solicit criminal activity. You also cannot advocate an imminent lawless action if it's likely to produce such an action: "Let's burn down that mosque" - not protected by free speech. You also can't make false promises (breach of contract), deceive people for profit (fraud), or make false statements that damage reputation with reckless disregard for the truth (defamation).
What about training videos? Is Ocean's Eleven a training video? What about Tom Clancy's Debt of Honor, 1994 that described something very similar to 9-11 attacks. Some people also don't want to see historical documents and books on things like Kamikaze pilots - what if terrorists act on these examples? It turns out they will come up with it themselves, even without such inspiration.
So, the court has to look at it from the point of view - are you intentionally aiding and abetting criminal activities?
What if a terrorist stays hidden and alive in the woods by reading a book on "how to fish"? It's clearly not intended to help criminals. That type of book is protected under free speech.
On software - it's usually (always?) something a human could do/calculate by hand, with time, but we're using the computer to help make it faster. If you hear statements from the government that is talking about restricting computers - remove the word "computer" and see if the same rationale for censoring instructions followed by people?
People are using encryption to protect files and conversations, as the FBI calls it "going dark". So, should we be allowed to publish encryption software? Imagine if you remove the computer from this situation
Jefferson and James Madison communicated via 'encrypted' messages, encoded. Thomas Jefferson distributed instructions that James Madison used, by hand, to encrypt private letters. No computer involved here, doing it by hand. What if they published how to do this in a book? And then a criminal used it, and the FBI comes and says you can't publish this. Is that allowed? If the book is intended to help criminals, the government can censor.
Lawyers will claim that free speech needs a software exception. Imagine sw made to destroy navigational systems on airplanes? What if it was a book that described how to do this? The computer is irrelevant to the question. The courts should look at the intent, just like they do when you present them with a book.
According to the FBI, in 1963, the Domestic Intelligence head thought he was a Russian agent. In 1964 he won the Nobel Peace Prize. In 1964 FBI sent King an anonymous letter encouraging him to commit suicide. In 1967, NSA also started surveillance on King.
As far back as 1977, the NSA (Joseph Meyer) threatened organizers of a crypto conference with prosecution under export laws.
For Dan himself, he sent a crypto paper and crypto software to NSA asking them for permission to publish. NSA refused, classifying paper and software as "munitions" and subject to export control. Though in 1995, the NSA told the courts they were trying to protect America - but papers were okay (free speech) and allowed Dan to publish the paper (but not the software).
Unfortunately for the NSA, Judge Marilyn Hall Patel disagreed with them in 1996, and agreed that software was free speech. It's just language. The court of appeals agreed in 1999.
Now back to modern day - Apple vs FBI - but imagine w/out the computer. Imagine the FBI coming to Jefferson and demand that he write a new anti-encryption instructions and falsely sign those instructions as being legitimate. Jefferson says that the instructions are too dangerous to create. The US Supreme Court notes that freedom of speech includes "both what to say and what not to say".
Ask yourself - what is the software doing in this picture? What if we were doing this ourselves? The courts know how to handle that and you should, too.
Zero knowledge system: A mathematical proof: zero knowledge proofs and verifiable secret sharing are vital for mutli-party secure sharing. Can be used in health care, blockchain, etc.
Can use blockchain in healthcare to exchange information across health care networks (for example between a hospital in DC and hospital in California).
How do you know you are working with an ethical party? Is the NSA ethical? What about Geek Squad? If you are building a zero knowledge system, will you be fostering bad ethics? For example, the blockchain for bitcoin contains child porn.
Think about free speech - you can talk about all things, but not necessarily incite behaviours. For example, you cannot shout fire in a theater.
So, you need a very clear Terms of Servie and Acceptable Use and a provisioning checkbox along the lines of "Will you be hosting illegal content?" Yes, they can break it - but then you will not have an ethical conundrum when law enforcement asks for that users illegal data.
Now, don't be a bad provider. Don't monitor your customer's content, be inconsistent or non responsive. Respect warrants - but use reason. Something doesn't seem right? Consult your lawyer, EFF, etc.
Rule #1 of cryptanalysis: search for plaintext first :-)
With the Snowden documents, we learned that the NSA is foiling much of the deployed encryption - using super computers, turnkeys, backdoors, etc.
If you can't get the plain text - try just asking for the key, then you can do the decryption. About 300,000 NSA letters for keys have been issued since 2001. Most come with gag orders, so it's difficult to get this information.
Yahoo fought the security letter they received. Others, like Silent Circle and Lavabit just shut down.
So, think about PFS - if someone gets one of your keys, can they get your older data as well? You can replace RSA with DH for perfect forward secrecy. logjam, though, was able to subvert the system by downgrading the negotiation and then read your data.
If you can't get the private key, try substituting the public key (because you have the private key for your public key!) The most recent attack in this area was fake SSL certificates or SSL person-in-th-middle attacks.
this brought about "Let's Encrypt" that has been live since 2015.
If you can't get the key, try cryptovirology (book by Young and Yung).
Or, how about a trapdoor in your PRNG (Dual EC DRBG, in Juno's ScreenOS).
What other technology might be similarly subverted?
If you can't undermine the encryption, how about attacking the end systems?
Hardware hacking: intercepted packages are opened carfully and a "load station" implants a beacon. If you don't want your routers to come with "extra bits", you might want to pick them up from the manufacturer (pictures shown of this happening to Cisco routers).
There is a chip that can be installed between monitor and keyboard, can be powered up remotely by radar and then the remote attacker can read what's on your screen.
Maybe we need offense over defense? How many 0-days do our governments have? Are they revealed to vendors? If so, when? NSA claims that they have released more than 90% of the 0-days to vendors, but didn't say anything about how long they hold onto the attacks before doing the notification.
another good way to fight encryption - complicated standards! Does anyone really fully understand IPsec, for example. Backdoors are another way, but we should be able to see from DUAL_EC_DRBG where the backdoor was backdoored....
There are 18Billion encrypted deployed devices to protect industry - not you. Like DRM to control content.
There are 14B encryption devises to protect users, but there are issues. Look at encryption on phones - it's not end to end, so still issues. Consumers might have "encrypted harddrives", but without key management, the hard drive can just be pulled out and put into another machine and read.
There are issues with many messaging services - they back up your messages in the clear in the cloud.
Secure channels are still a challenge with lack of forward secrecy, denial of service, lack of secure routing, and lack of control over meta data (which is still data!) TOR hides your IP address, but not your location, so it is limited.
when doing design, avoid a single point of trust that becomes a single point of failure. stop collecting massive amounts of data.
distributed systems work: Root keys of some CAs, Skype (pre-2011) and bitcoin.
We need new ways to detect fraud and abuse. We need open source solutions, open standards, effective governance and transparency for service providers. And finally, deploy more advanced crypto.
We still don't know what the policies are going to be, yet, but she's here to give us her understanding of where we are and where she thinks we're going.
Why should you care, if you're not a lawyer? Look at lavabit - a company that offered an encrypted email service. All was well and good until it was discovered that Edward Snowden used their service. The US Government requested their encryption keys (under a gag order, so they could not tell their users). Judge ordered them to give up their keys. Not just the keys that protected Snowden's mail, but to everyone's. The company shut down, because they no longer felt they could protect their users.
Right now we are seeing a very divided government, polar opposites on a lot of issues - but they will work together on preventing NSA surveillance and protecting encryption keys.
Obama administration considered various technical options to get around the "going dark" problem - so law enforcement could access information they had before encryption became more pervasive. Several things like backdoors, remote access, forced updates, etc - and the administration decided to work with the commercial providers of the products, as opposed to building legislation.
We don't know clearly where the Trump administration stands, we know that Trump was critical about Apple not wanting to give a back door to law enforcement to get into an iPhone. Jeff Sessions noted once that he was in favor of encryption, but that criminal investigators need to be able to"overcome" encryption.
There is proposed legislation from Burr/Feinstein that requires manufactures provide data in "intelligible forms" (covers software and device manufacturers.). The ACLU is not in favor of this bill. It has been called "technically tone deaf".
We know that under the Obama Administration had an interagency process run out of the White HOuse that didn't have any "hard and fast rules" on vulnerability disclosure. It was used to balance risk with intelligence needs. NSA said most vulnerabilities are disclosed. Is that good enough to protect users of tech?
NSA surveillance: Section 702. This targets 106,000 foreign targets where they collect over 250 million internet transactions annually, about 50% of that information is about a U.S. resident. This is up for review again this year in congress.
Because of Trump's accusations of wire tapping, this may be an opportunity to reform Section 702.
Right now, based on a 6th circuit court decision from 2010, most US companies require a warrant before they will provide content to the FBI or other law enforcement.
An email privacy act was passed by congress 419-0, but the bill got stuck in the senate where too many unrelated thongs were added.
Many users would be surprised at the low bar required to hand over their data to the FBI or local law enforcement, or that they also would not necessarily be notified when it happens.
If you're building products for the government, think about how the product will be used and can you audit that it's being used as intended?
Look to see what lobbyists your employer is backing and see if it lines up with their public press releases - if not, say something. Consider also direct lobbying - there is a dearth of technical knowledge in Capital Hill - they need your knowledge!
Developers often don't know where the crypto is happening. They may forget to complete certain code segments, relay on 3rd party and open source and rely on multiple frameworks. Or even if they do, they may not want to dive in because of the amount of work required to make things work correctly, particularly from a FIPS perspective..
What about the FIPS code review done by the lab? Almost certainly not, as they are typically looking at the application code - just the low level crypto and RNG functions. Even with the old German scheme for EAL4 deeper code review, still miss issues (like the above TODO code that went through EAL2 and EAL4 review). Testing misses these nuances as well.
Security audits of your code are very fruitful, but very expensive. He's seen success with bug bounty programs, even if the code is closed.
He's also seen problems with FIPS deployments that are leveraging "FIPS inside" where they leverage another module, like OpenSSL, but forgot to turn on FIPS mode and forgot to update the applications so they would not try to use non-FIPS algorithms.
Another problematic approach - the dev follows all the steps to deploy CenOS in FIPS mode by following the RedHat documentation... except that documentation only applies to RedHat and *not* CentOS. Yes, it's the same source code , but validations are not transitive. A RedHat validation only applies to RedHat deployments.
To get this right, identify services that really need to be FIPS validated and focus your efforts there..
Matthew Green, Johns Hopkins University.
Kleptography - the study of stealing cryptographic secrets. Most people did not think the government was really doing this. But, we do know there was a company, Crypto AG, that worked with the NSA on their cipher machines available between 1950s and 1980s.
Snowden's leak contained documents referring to SIGINT - a plan to insert back doors into commercial encryption devises and add vulnerabilities into standards.
How can the government do this? We can't really change existing protocols, but you can mandate use of specific algorithms. This brings us to the 'Achilles heel' of crypto - (P)RNG. If that's broken, everything is broken.
There are two ways to subvert an RNG - attack the lower level TRNG or the PRNG. The TRNG is probabilistic and hardware specific and too much variance. The PRNG/DRBG is software and everyone has to use a specific one to comply with US Government standards - a more appealing target.
Young and Yung predicted an attack against the DRBG and how it might work in the 1990s - where you could use internal state, a master key and a trap door will let you decrypt the data. This sounds a lot like Dual EC DRBG. It was almost immediately identified as having this weakness - if the values were not chosen correctly. NSA chose the values - and we trusted them.
Snowden leaks found documents referring to "challenge of finesse" regarding pushing this backdoor through a standards body. Most of us don't have to worry about the government snooping on us, but ... what if someone else could leverage this back door?
This is what happened when Juniper discovered unauthorized code in their ScreenOS that allowed an attacker to passively decrypt VPN traffic. Analysis of the code changes discovered that Juniper changed the parameters for DUAL EC DRBG. But, Juniper said they didn't use Dual EC DRBG, according to their security policy, other than as input into 3DES (which should cover anything bad from DRBG). The problem came up when a global variable was used in a for loop (bad idea), which in effect means the for loop that was supposed to do the 3DES mixing never runs (as the Dual EC DRBG subroutine also uses the same global variable).
More specifically, there are issues with how IKE was implemented. The impacted version, ScreenOS 6.2 (the version that adds Dual EC DRBG) adds a pre-generation nonce.
Timeline: 1996 Young and Yung propose the attack, 1998 Dual EC DRBG developed at NSA, 2007 became a final NISt standard, 2008 Juniper added Dual EC DRBG and it was exploited in 2012 and not discovered until 2015.
Before Dual EC DRBG, people used ANSI X9.31 - which had a problem if you used a fixed K, someone can recover the state and subvert the systems.
How do we protect ourselves? We should build protocols that are more resilient to bad RNG (though that's not what is happening). But maybe protocols are not the issue - maybe it's how we're doing the validation. Look at FortiOS, who had a hard coded key in their devices, which was used for testing FIPS requirements, and documented it in their security policy.
A good quote starts: "There is no difference, from the attacker's point of view, between a gross and tiny errors. Both of them are equally exploitable."..."This lesson is very hard to internalize. In the real world, if you build a bookshelf and forget to tighten one of the screws all the way, it does not burn down your house".
We look for the following in network transport encryption: data exposure, network intercept, credential theft, identity theft, authenticated cipher suites, etc.
We have learned, the hard way, the problem with unauthenticated block modes. If you don't compute the hash correctly or in the wrong order - it's useless.
After POODLE, SSLv3 is dead. It's still out there, but as a practical matter, it's gone.
Getting good data on who is impacted by a security vulnerability is hard - even Gartner got this wrong, by overestimating who was impacted by FREAK just by how many devices still supported SSLv3 (even if they did not actually have the vuln).
Advice going forward: use AEAD!
This is an older toolkit, Jeff fell in love with it when he was in college in the 90s. He's been working in computer security ever since.
Crypto++ is a C++ class library, written by Wei Dai in June 1995. It's a general purpose crypto library, handed over to the community in 2015. https://www.cyrptopp.com/
When the library was hit with CVE in 2015, he handed it over to the community to develop. Since Jeffrey has been using it since 1990s, he was chosen to become one of the maintainers. Wei Dei still advises.
C++03 through C++17 have heavy use of templates and static polymorphism (yay C++). Makes things faster, but makes it hard to adopt, especially as there is not excellent documentation. He tries to use questions on stackoverflow to demonstrate where to spend time on the documentation.
Right now, crypto++ is on the historical validation list, which makes it pretty much useless... (them and everyone else ended up on the list last year, due to DRBG changes).
Crypto++ validations are on Windows only. Includes NIST approved algorithms; RNG, AES, SHA, MAC, RSA, DH. There are non-FIPS routines in other DLLs.
Going forward, he'd like to add C bindings. Would like to add an engine-like interface. Will they do another validation? Probably not - too expensive. But, could wrap around other validated crypto to take advantage.
Crypto++ now uses OpenSSL's FIPS Object Module, to effectively provide a FIPS validated module - so you can stay on your C++ bindings and not make changes to your application.
Going forward, he
TLS is the protocol that secures the internet, and there are very few alternatives. It's a session layer protocol for other protocols, and it is very complex. Sure, you can implement it in 3 weeks - but will you get it right?
TLS is under scrutiny and there is growth in the number of attacks and their frequency.
We need to make sure we understand the attack properly and understand the practical impact. How reproducible is the attack? how can we fix it and make sure it stays fixed? Customers often don't understand the impact or how to fix.
Scapy TLS is TLS & DTLS scriptable stack built above scapy. It's as stateless as possible, includes packet crafting and dissecting and crypto session handling.
The goals of the project are to make sure it's easy to install and use to simplify discovery and exploitation of TLS vulnerabilities - very customizable.
We then got to see some code - it looks very simple to use.
The theory here is you can use this tool to help work on PoCs faster. It's on GitHub :)
TLS 1.0 was a slight modification of the original SSL protocol by Netscape, published in January 1999. Basically the same as SSL3 - it is bad, it is weak, it has no good ciphers and it's still in wide use.
TLS 1.1 came out in April 2006. It would be great to kill both TLS 1.0 and 1.1 off - but it's just too hard.
TLS 1.2 has been around since August 2008. Since then, there's been a bunch of new RFCs and algorithms from all over the world.
TLS 1.3 was approved in October 2015 in IETF.
Background on IETF: If it doesn't happen over email where everyone can see it, it didn't happen. It is divided into areas like Security, Operations, DNS, etc - each area has area directors and working groups and working group chairs. Very well laid out process, very egalitarian.
The working groups work by consensus - they demonstrate by humming, so people can't be singled out by raising hands or doing a verbal roll call. Many documents now do their iterations in GitHub.
IETF also has RFC editors who make sure final revisions follow the consistent and correct format for an RFC.
TLS 1.3 had a few goals - encrypt as much of the handshake as possible, reduce the handshake latency - ideally to one or zero roundtrip for repeated handshakes, update record payload and make it more privacy friendly.
Only uses ECDH and DHE (but nobody will use DHE - too expensive). All connections have perfect forward secrecy. Most things are encrypted (SNI is not). The most common curves will be NIST P-256 or X25519.
There will be improvements to bulk encryption. Three cipher types and two variations: ChaCha220/Poly1305, AESGCM128(256) and AESCCM 128 (256). The cipher lists and choices were just getting too long and mistakes were being made. these are the ones you need. The cipher suite no longer specifies key exchange or authentication mechanism - they are negotiated now.
The bulk encryption ciphers chose are all modern, secure and AEAD-only - in addition to confidentiality, you also get integrity (authenticity).
Authentication improvements: DSA was removed, RSA was kept and prefers RSA-PSS over PKCS #1.5.
There was general cleanup, like the removal of renegotiation (ie export crypto). Almost every message now has extensions: OCSP or Certificate Transparency stapling on server and client side. There is now padding at the TLS layer (this was slightly controversial). There is only one hash mechanism: HKDF (RFC 5869) and it's used consistently (and correctly). They've done cryptanalysis and attack events, found issues and fixed them. There will be no SHA. Does that mean SHA3 is no good? No, there were just concerns about performance and newness when TLS 1.3 work started.
SHA will still be around in certificates, though even SHA1 is being rapidly phased out.
Renegotiation is gone. There were many use cases: request client cert, "step-up" crypto algs and re-key. It was buggy and unclean and a source of problems. Only strong crypto is available.
There is allowance for session resumption. It prefers sessions over tickets. Sever can send session information at any time and the session is like PSK. PSK is like session resumption. If you're reconnecting, send data with the resumption :-) This gets you O-RTT - Zero Round Trip Tickets.
0-RTT: client connects, C&S do the ECDHE dance. Client remembers the server's key share. Next time, client reconnects and sends data encrypted with that key. This helps to avoid an extra round-trip with less latency. This makes your web faster and then we can all make more money.
0-RTT has a big butt... there is no PFS with early data. That data can be replayed elsewhere (GEt is idempotent). Nobody was really listening to these concerns until Colm@Amazon spoke and posted two weeks ago. No everybody's trying to figure out what to do. We want to do the right thing, but one of the primary goals was to improve performance - and browser vendors will use it anyways.
TLS 1.3 status is very close to IESG review. Chrome and FF and some others are at Draft-18. Draft 19 had minor changes, Draft 20 is incompatible.
BYOK suggests a one-way mechanism: your key, my cloud.
The word "Key" tends to be generally understood in a very broad sense (symmetric and asymmetric), however in cloud service providers it has a bit of a different definition.
The current key management servifes offered are MS Azure, Amazon AWS and Google Cloud Platform. Azure uses Thales and Amazon uses Gemalto, Google doesn't appear to use an HSM at this time. Their biggest differences are around the BYOK protocols (key wrapping, etc).
BYOK is an important tool, but should not be the only tool in your tool box. It will help you get your own key into the cloud, so you know it meets your standards for generation. The cloud provider will handle things for you, but not in a consistent way - so lots of hurdles to go through to get this done.
MYOK - Manage Your Own Keys! MYOK implies you can manage import/export, lifecycle and generation all by yourself. Provision when you need them, destroy when you're done. How can you do this in a way that is meaningful for your business?
Centralized key managers are moving into the market space.
Key management is more than just keys - name, algorithm, length, export settings. And, many key formats end up being very vendor specific (some use standards like PKCS#8, but many more are just proprietary).
Steve Marquess - OpenSSL
David Hook - Bouincy Castle
Kenn White - Open Crypto Audit
Nicko van Someren - Linux Foundation
There are many implementations of TLS, from C and assembly implementations to Java implementations. OpenSSL has many forks - some obvious, some hidden under the covers. More implementations are good, as we don't want to suffer from monoculture.
There is possible value in creating a drop in API that multiple implementations could use. Nicko suggests creating an open process to create that API - it would not necessarily be from an existing implementation. It could possibly allow for more automation. APIs tend to grow out of necessity, and are not always pretty. A common API could help with security and fuzz testing.
There was then a long side discussion on libsodium (NACL), which is only a crypto library at this point as the "N" piece of networking/TLS hasn't been implemented, yet, but there are lots of language bindings out there.
How long does it take to create a new TLS library? Apparently a new one was created recently in 3 weeks - leveraging someone else's crypto. Language choice is important.
The older APIs have to consider legacy deployments, for example OpenSSL still supports VAX/VMS. Another perspective - a new TLS implementation has taken another team 5 months already. When you have a user base you need to support, that seems to add time to the implementation.
There was a question about moving your implementation from TlS 1.0 to TLS 1.3? One of the OpenSSL developers noted that there is a lot of code reuse, but also a lot of #ifdefs. (TLS 1.0 is not, yet, #ifdef''d out of OpenSSL, but probably will be within the year).
There was a question about what is the biggest issue with FIPS validations? The general answer: consistency. That is, OpenSSL helped take multiple validations through at the same time, which was based on the same code and mostly the same documentation took a different amount of time and got completely different feedbacks.
In July 2016, OpenSSL announced the commencement of a fresh attempt to do a FIPS validation of OpenSSL. There are over 244 validated products on the NIST list that obviously use OpenSSL in their validation boundaries and it's included in most (all?) operating systems - it's pervasive! So, why is it so hard to validate? It starts out as open source with lots of competitors/stakeholders interested in it.
Unfortunately, stakeholder goals and project goals do not always align. For example, the project wants to support many platforms - stakeholders want to focus on only one or two. The same goes for the number of algorithms supported and validated.
Previously, FIPS140 work was effectively entirely funded for the OpenSSL project from 2009-2014, as there was no long term or major sponsor at this time. The sponsors funding OpenSSL FIPS all had different goals (other than wanting to sell into the US government), which made it very difficult to manage. This is a hard project, with many people yelling at you with different goals and wasn't very rewarding - can't just expect people to do this for "fun". [note: yes, nothing about FIPS is "fun" - practical, yes, but not fun]
The first validation was very painful for the developers, so OpenSSL knows they have to do it differently if they are ever going to do it again. OpenSSL started their first FIPS 140-2 validation in June 2002, certificates were not received until March 2006!
There have been a total of 9 unique validations, to keep up with new hardware platforms and implementation guidance changes.
The OpenSSL FIPS 1.0 module based off of the OpenSSL-0.9.x is no longer usable, there is still a bit of life left in OpenSSL FIPS 2.0 module (#1747, #2389, #2437) as it is based off of the OpenSSL-1.0.x code. But, a major update is required for a new OpenSSL FIPS module to work with OpenSSL-1.1.x. For this go round, goal is to make the FIPS140 related changes "less intrusive".
Current validations cover dozens (hundreds?) of platforms (OS vs hardware).
For the new validation, the only current sponsor is SafeLogic, but additional sponsors are needed to fund OpenSSL FIPS development and FIPS lab testing - resources are available now to begin work.
This is a high risk validation, many people will be watching the validation which means people are cautious to enter - which creates a longer timeline. Keep in mind that TLS 1.3 is only available in OpenSSL 1.1.x, so if that's important to your customers, consider helping out financially to get this project going.
It's hard to get the sponsors on board, as they all want to see another sponsor already on board and to share the cost, but they still want to wield great influence over the work.
If this project doesn't happen, there are fewer options for FIPS libraries and will require you to do more of your own FIPS work. Taking multiple versions from different companies through CAVP/CMVP is a waste of their resources as well. Also, if everyone develops independently, the federal government will end up with inconsistent implementations.
Originally team was going to work on FIPS 140-2 work before TLSv1.3, but swapped the priorities. That was easier to get a sponsor for, as it's well defined project and now the FIPS work can happen with the TLSv1.3 in place.
OpenSSL has refactored algorithm testing approach and want to better support embedded systems, and do better with entropy generation. Need to pick up extra NIST work and try to take SHA3 through CAVP/CMVP.
Will continue to look at improvements to POST (like defining what it means for software). Also considering add ChaCha/Poly1305.
Currently cannot commit to many requested features, just due to trying to keep a reasonable timeline. The current schedule estimate from "start" to certificate is 18months, based on their experience taking other modules through.
Please consider sponsoring this project so it can get off of the ground!
Open Source is huge and it's here to stay, with nearly 4 million contributors world wide, 31 billion lines of committed open source, etc - we aren't getting away from it now! Open Source is the "roads and bridges" of the Internet, which runs on Open Source.
Sometimes open source breaks... things like heartbleed, shellshock, Poodle, etc. The Internet runs on opensource, but it's not always properly looked after. Linus's Law: "Given enough eyeballs, all bugs are shallow" - so why are there still bugs? Well, not enough eyeballs!
Open source software is not more or less secure than closed source - but different. Typically there are more diverse group of people working on the source, but serially over a long period of time. There is often a culture of "code is more important than specification" - a cultural difference from most businesses.
Major projects are very under resourced, like OpenSSL - run by millions of businesses, but only got $2000 in support in 2013. NTPD is run by every major stock exchange, but some of the code is 35 years old, maintained by one guy, part time. Same for bash, GnuPG, and OpenSSH.
These open source projects are not given the resources they deserve.
The Linux Foundation created the Core Infrastructure Initiative. The CII aims to substantially improve security outcomes in the OSS projects that underpin the Internet. The CII funds work in security engineering, security architecture, tooling and training on key OSS projects.
This market is changing quite quickly as well - who would've known 4 years ago how important node.js would be?
CII is a non profit funded by industry partners, like Intel, Microsoft, Google, Hitatchi, Dell, Cisco, Amazon, Bloomberg, Fujitsu, etc.
Open source can do all of the same things commercial enterprise does for building secure software - just harder, because there is no way to give a top-down mandate (ala Bill Gates fixing security mindset at Microsoft).
Groups and individuals must think about security early and often, it cannot be just one squeaky wheel mentioning security. It requires buy-in from the entire community. Fostering this culture of security within your open source project is the single most important thing that you can do to improve your security outcomes. Security needs to be given equal weight with scalability, performance, usability and other design factors.
CII is trying to find out where the risks and problems are by doing the CII Census Project to discover the really critical open source projects, how responsive the developers are, historic trends for bug and vuln density and how healthy the development community is. Did a snapshot a couple of years ago and created a scorecard. working now on updating it to be a continuous evaluation.
Once critical projects have issues identified, CII is trying to focus their resources on fixing it. Maintenance work is not fun, but it is vital. They are trying to pay developers to work on key projects full time, match willing and able developers to relevant projects and encourage educational establishments to get students involved.
Additionally, working on improving open source security tools. This means funding development of new or improved OSS security tools, make sure they are usable and have a good signal to noise ratio. Problem with some of the existing tools - terrible documentation! So, there is even a need for paying people to write documentation for how to use and deploy continuous security testing.
CII also wants to drive better security process in OSS projects with their CII Badge program - an open process for evaluating security processes in your community. It's a self assessment, with the goal of avoiding security theater, so it only includes items that really improve security.
CII has a travel fund to send developers to security conferences to learn about security and additional funding to get key OSS developer teams to meet face to face to set priorities and collaborate (like OpenSSL).
If your company is building your business on open source software, you should consider funding those projects and CII to help push better security practices, etc.
Tomorrow is a highway broad and fair,
And we are the many who'll travel there.
Tomorrow is a highway broad and fair,
And we are the workers who'll build it there;
And we will build it there.
Come, let us build a way for all mankind,
A way to leave this evil year behind,
To travel onward to a better year
Where love is, and there will be no fear,
Where love is and no fear.
Now is the shadowed year when evil men,
When men of evil thunder war again.
Shall tyrants once again be free to tread,
Above our most brave and honored dead?
Our brave and honored dead.
O, comrades, come and travel on with me,
We'll go to our new year of liberty.
Come, walk upright, along the people's way,
From darkness, unto the people's day.
From dark, to sunlit day.
Tomorrow is a highway broad and fair
And hate and greed shall never travel there
But only they who've learned the peaceful way
Of brotherhood, to greet the coming day.
We hail the coming day.
("Tomorrow Is A Highway" -- words by Lee Hays, music by Pete Seeger)
We didn't know how it was going to turn out. We thought she'd be in prison for decades more. And then, even after President Obama commuted her sentence, I remained privately worried that something would happen, some snag or tragedy. Yesterday she got to have a hot slice of pizza -- so a few people gathered at my apartment and shared pizza and toasted her release. It was so good to have something to celebrate with friends.
I've been listening over and over to "Tomorrow Is A Highway". It's got some lovely stark lines, like "leave this evil year behind." Time and space have unified ; it doesn't say that we'll walk into the future, but rather, that the future is this journey, and there are only two time durations in this song, days and years -- tomorrow is a highway upon which we'll travel to a better year. And it's sort of a mix of prescriptive and descriptive, prophetically defining us as the people who are making this tomorrow. This song does not explicitly say "this might happen" or "we should hope for this to happen"; instead it combines "this will happen" and "let's make it happen". It's less a song of hope, and more a song of faith and promise and invitation.
It can be hard to let go of hope, and it can be hard to let go of dread. I can stop holding my breath now. She's out. We've moved from promise to fact.
I can't seem to find my copy of Ursula K. Le Guin's The Dispossessed at the moment -- did I lend it to you? In it, Shevek thinks a few times about how our conception of time and promises and intentions work together -- a coherent future doesn't just happen, it's intentional human actions that make a "road" and breaking promises denies and breaks that "road" connecting past, present, and future.
I have been feeling as though nothing is solid under my feet. And part of that is that I couldn't trust that she'd really get to be free. But now she is. And for the sake of my own forward motion I shall work as though the next stretch of the road exists too -- perhaps every step is in some measure a leap of faith.
And then I'll fly straight from there to Madison for WisCon. I am not on any panels at WisCon this year but I'm the auctioneer for the auction benefiting the Tiptree Award. This year's auction includes a signed first edition hardcover of Octavia Butler's novel Wild Seed, an "Elect Alison Hendrix" pin from Orphan Black, an art print of "Aswang, at Night" by M Sereno, and a bunch more.