- Men Explain Technology to Me: On Gender, Ed-Tech, and the Refusal to Be Silent: Hack Education (November 18th): “There’s a problem with the Internet. Largely designed by men from the developed world, it is built for men of the developed world. Men of science. Men of industry. Military men. Venture capitalists. Despite all the hype and hope about revolution and access and opportunity that these new technologies will provide us, they do not negate hierarchy, history, privilege, power. They reflect those. They channel it. They concentrate it, in new ways and in old.”
- Uber Executive Suggests Digging Up Dirt on Journalists | BuzzFeed (November 17th): “A senior executive at Uber suggested that the company should consider hiring a team of opposition researchers to dig up dirt on its critics in the media — and specifically to spread details of the personal life of a female journalist who has criticized the company.”
- The moment I learned just how far Uber will go to silence journalists and attack women | PandoDaily (November 17th): “I have known many of Uber’s key investors and founders personally for six to ten years. Over that time I’ve seen an ever-worsening frat culture where sexist jokes and a blind eye here-or-there have developed into a company where the worst kind of smearing and objectification of women is A-ok.”
- Gender, Race, and the Supernatural: Appreciating Sleepy Hollow’s Abbie Mills | Ms. Magazine Blog (October 29th): “Still, it’s one of the few shows featuring a black woman character who is not only kicking butt and taking names in her various encounters with demons, sorcerers, ghosts and zombies, but is constantly saving our white male hero and acculturating him into our 21st-century era: including driving automobiles, learning which mobile phone devices are the most up-to-date, and more recently, practicing yoga.”
- Sweden Considers Special Labels for Sexist Video Games | Time (November 16th): “A government-funded innovation agency in Sweden is considering creating specials label for video games based on whether or not the games’ portrayals of women are sexist.”
- Update: the following two links criticize Sweet Peach as described by Austen Heinz and Gilad Gome. Founder Audrey Hutchinson says her company, aiming to produce individualised probiotic mixes for vaginal use, was seriously misrepresented (November 23).
- These Startup Dudes Want to Make Women’s Private Parts Smell Like Fresh Fruit | Inc (November 21): “At the DEMO conference in San Jose, California, on Wednesday afternoon, Heinz and Gome outlined their shared vision and previewed plans for a new probiotic supplement that will enable women to change the way their vaginas smell. Called Sweet Peach, it will be made using Cambrian Genomics’ DNA printing technology and financed through a campaign on the crowdfunding platform Tilt.”
- How Not to Disrupt Women’s Bodies | Inc (November 21st): “Since time immemorial, beauty and feminine hygiene companies have used the promise of personal empowerment to help sell equally reprehensible, if much more subtle, campaigns based around negging women and then offering the solution to all of their bodily imperfections. Or smells. Especially smells. Poor Sweet Peach, trying to put a “probiotic supplement” gloss on what’s essentially the boring old douche market.”
- Three Tactics that Block Women from Getting Ahead | Accidentally in Code (November 19th): “There are different kinds of gendered experiences. The outright sexual harassment, versions of “get back in the kitchen” is one, but another is patterns of behaviour that happen over, and over again to women, but much more rarely to men. It’s behaviour that men feel more OK with exhibiting towards women, because subconsciously they know they are much more likely to get away with it.”
- Meet the Women Challenging the Media and Tech Establishments | Fast Company (November 17): “Not many journalists would leave a high-profile job at one of America’s most storied newspapers to create their own startup. But that’s exactly what former Wall Street Journal reporter Jessica Lessin did last year when she founded the tech news site The Information.”
- Tech Freedom vs. Feminism | On the Left (November 19): “Several prominent tech freedom organisations choose to align themselves with and refuse to depose these kinds of men, no matter how horrible the shit against them is. The men themselves get away with harassing and abusing women because they are seen as being ‘valuable’ to the movement. Once you’re up on a tech freedom pedestal, it seems like it’s impossible for someone to bring you down.”
We link to a variety of sources, some of which are personal blogs. If you visit other sites linked herein, we ask that you respect the commenting policy and individual culture of those sites.
You can suggest links for future linkspams in comments here, or by using the “geekfeminism” tag on Pinboard, Delicious or Diigo; or the “#geekfeminism” tag on Twitter. Please note that we tend to stick to publishing recent links (from the last month or so).
Thanks to everyone who suggested links.
Happy Doctor Who Day, everyone! Come get some CAKE!
Gotta kick things off with the world's most famous blue box, and this one is a whopping four feet tall!
I wanted to show off more than just the TARDIS, though, so here are some sweet Who villains to liven up the party:
A Cake Cyberman? Now THAT is an upgrade.
But I'd still be willing to exterminate this Dalek...
(By Mike's Amazing Cakes)
...WITH MY MOUTH.
If you have to make a cake of the Doctor's most terrifying villain, then I say, turn the Doctor into a bunny rabbit! That way the cute will even out the scary, like so:
(Also by Mike's Amazing Cakes)
Don't blink - 'cuz that bunny Who is too sweet to miss!
Careful, though; I think the Weeping Angel is peeking:
Do you believe in delicious irony?
(By Eat the Evidence)
Because eating a cakey adipose is wrong in all the right ways.
And not a villain at all, but check out this outstanding Ood!
I hear his translation sphere even lights up!
Of course, we can't celebrate Doctor Who without the Time Lord himself:
(By Pink Cake Box)
As dashing as Eleven looks, I can't get over the open TARDIS door. WOW.
And here's one with homages to both Ten & Eleven:
(By Un Jeu d'Enfant)
Bow ties and fezzes and 3D glasses, oh my!
I love that the good Doctor is popping up in more themed weddings these days. Check out the oh-so-elegant Gallifreyan writing on this beauty:
(By Nom Nom Sweeties)
And here's John's favorite: an explosion of color with lots of Whovian surprises!
(By Artisan Cake Company)
I spy an adipose, an angel, and an ambushing Dalek!
And for the hardcore fans, let's see how much of this next one you recognize!
(By Delicious Snackies)
I see the fourth Doctor's scarf, a Time Lord's medallion, the crack in time (so cool), roses, Gallifreyan text, and I *think* that's a sonic screwdriver and the Master's pocket watch on top. WOWZA.
(Hit the link for more pics of the bottom tier; did anyone translate it yet?)
And finally, a gorgeous pop of classic colors and great design:
(By Cake Central member Emilsmee)
Love that bold red outlining, and the hand-painted tier of the famous Van Gogh "exploding TARDIS" is just perfect!
Hope you enjoyed today's Timey Wimey treats, everyone! No go forth, and be wibbly wobbly!
Be sure to check out our Sunday Sweets Directory to see which bakers in your area have been featured here on Sweets!
Update: Aha! Thanks, guys; these are by Drew Green. I don't see an online store, but hit the link to see more of his work on DeviantArt.
And speaking of originals, how about this ink-on-wood Alice in Wonderland by Sze Jones?
here, but I don't see any prints available. (Boo!) However, over on Sze's website I saw she made the same design for the cartoon version, and it's really cool to contrast the two!
Sze's site for more of her work!
K, I think that does it for this month, guys! As always, comment below for your chance to win your choice of free art from my Pinterest Art Give-Away Board. I'll ship anywhere, so internationals are welcome, and I'll announce the randomly selected winner in a few days.
Good luck, and happy commenting!
I’ve made several calendars since I wrote about them last. I figured out how to do early November: I had day boxes for the day activities and night boxes showing him which other family members were sleeping in the same house as him that night.
Yesterday, for the first time, he requested one. It turned out that he wanted one because he thought he could persuade me to put skiing on it, and that in turn, if I put skiing on the calendar we would definitely for sure go skiing for a week within the month.
Not so much. (Today the forecast maximum is 35°C.)
But I did one anyway:
This one also has an international trip: on the days labelled “Dad”, A and I will be in New Zealand. (That’s also why he misses the swimming lesson that week: Andrew will need to use childcare on Friday.)
You can guess at a few things. We’re going on a picnic today. He’s going to the dentist Friday. (In fact, he is a bit scared about that, so I partly made the calendar so as to not have to explain every day for a week that it isn’t yet dentist day.) There’s a couple of Christmas parties. What’s not immediately obvious, but I explained to him: this calendar shows his last three weeks of kindergarten transition. It also shows his last four weeks at his daycare, ever. He’s been at this daycare for three years now, and a year and a half at the one before that. He’s not going to kindergarten with one single kid from the daycare. In terms of gigantic things that have happened to him, probably only our move when he was two years old was bigger. For more or less the same reason, his swimming lessons also end with this calendar.
In four weeks he’s done with daycare. In ten weeks, he starts school.
Aaaa, this blast from the past rolled around on my partner's spotify tonight. So much power pop goodness...I have ~feels~ about this song. ^_^;
Also notable: apparently Weezer did a cover of this song for the movie Cars 2. It's pretty good! They didn't stray very far from the original. =)
He arrived today!
He’ll be coming along to his first Ubuntu event on December 10th, a San Francisco Ubuntu Hour.
This year I’ve traveled more than ever, but almost all of my trips have been for work. This past week, MJ and I finally snuck off for a romantic vacation together in Jamaica, where neither of us had been before.
Unfortunately we showed up a day late after I forgot my passport at home. I had removed it from my bag earlier in the day to get a copy of it for a VISA application and left it on the scanner. I realized it an hour before our flight, and the check in was 45 minutes prior to, not enough time for me to get home and back to the airport before the cutoff (but I did try!). I felt horrible. Fortunately the day home together before the trip did give us a little bit of breathing room between mad dash from work to airport.
Friday evening we got a flight! We sprung for First Class on our flights and thankfully all travel was uneventful. We got to Couples Negril around 3PM the following day after 2 flights, a 6 hour layover and a 90 minute van ride from Montego Bay to Negril.
It was beautiful. The rooms had recently been renovated and looked great. It was also nice that the room air conditioning was very good, so on those days when the humidity got to be a bit much I had a wonderful refuge. The resort was all-inclusive and we had confirmed ahead of time that the food was good, so there were no disappointments there. They had some low-key activities and little events and entertainment at lunch and later into the evening (including some ice carving and a great show by Dance Xpressionz). As a self-proclaimed not cool person I found it all to be the perfect atmosphere to relax and feel comfortable going to some of the events.
The view from our room (2nd floor Beachfront suite) was great too:
I had planned on going into deep Ian Fleming mode and getting a lot of writing done on my book, but I only ended up spending about 4 hours on it throughout the week. Upon arrival I realized how much I really needed the time off and took full advantage of it, which was totally the right decision. By Tuesday I was clear-headed and finally excited again about some of my work plans for the upcoming weeks, rather than feeling tired and overwhelmed by them.
Also, there were bottomless Strawberry Daiquiris.
Alas, it had to come to an end. We packed our things and were on our way on Thursday. Prior to the trip, MJ had looked into AirLink in order to take a 12 minute flight from Negril to Montego Bay rather than the 90 minute van ride. At $250 for the pair of us, I was happy to give it a go for the opportunity to ride in a Cessna and take some nice aerial shots. After getting our photo with the pilot, at 11AM the pair of us got into the Cessna with the pilot and co-pilot.
The views were everything I expected, and I was happy to get some nice pictures.
Jamaica is definitely now on my list for going back to. I really enjoyed our time there and it seemed to be a good season for it.
More photos from the week here (admittedly, mostly of the Cessna flight): https://www.flickr.com/photos/pleia2/set
In April 2014, this blog featured a story about Lance Ealy, an Ohio man arrested last year for buying Social Security numbers and banking information from an underground identity theft service that relied in part on data obtained through a company owned by big-three credit bureau Experian. Earlier this week, Ealy was convicted of using the data to fraudulently claim tax refunds with the IRS in the names of more than 175 U.S. citizens, but not before he snipped his monitoring anklet and skipped town.
On Nov. 18, a jury in Ohio convicted Ealy, 28, on all 46 charges, including aggravated identity theft, and wire and mail fraud. Government prosecutors presented evidence that Ealy had purchased Social Security numbers and financial data on hundreds of consumers, using an identity theft service called Superget.info (later renamed Findget.me). The jury found that Ealy used that information to fraudulently file at least 179 tax refund requests with the Internal Revenue Service, and to open up bank accounts in other victims’ names — accounts he set up to receive and withdraw tens of thousand of dollars in refund payments from the IRS.
The identity theft service that Ealy used was dismantled in 2013, after investigators with the U.S. Secret Service arrested its proprietor and began tracking and finding many of his customers. Investigators later discovered that the service’s owner had obtained much of the consumer data from data brokers by posing as a private investigator based in the United States.
In reality, the owner of Superget.info was a Vietnamese man paying for his accounts at data brokers using cash wire transfers from a bank in Singapore. Among the companies that Ngo signed up with was Court Ventures, a California company that was bought by credit bureau Experian nine months before the government shut down Superget.info.
Court records show that Ealy went to great lengths to delay his trial, and even reached out to this reporter hoping that I would write about his allegations that everyone from his lawyer to the judge in the case was somehow biased against him or unfit to participate in his trial. Early on, Ealy fired his attorney, and opted to represent himself. When the court appointed him a public defender, Ealy again choose to represent himself.
“Mr. Ealy’s motions were in a lot of respects common delay tactics that defendants use to try to avoid the inevitability of a trial,” said Alex Sistla, an assistant U.S. attorney in Ohio who helped prosecute the case.
Ealy also continued to steal peoples’ identities while he was on trial (although no longer buying from Superget.info), according to the government. His bail was revoked for several months, but in October the judge in the case ordered him released on a surety bond.
It is said that a man who represents himself in court has a fool for a client, and this seems doubly true when facing criminal charges by the U.S. government. Ealy’s trial lasted 11 days, and involved more than 70 witnesses — many of the ID theft victims. His last appearance in court was on Friday. When investigators checked in on Ealy at his home over the weekend, they found his electronic monitoring bracelet but not Ealy.
Ealy faces up to 10 years in prison on each count of possessing 15 or more unauthorized access devices with intent to defraud and using unauthorized access devices to obtain items of $1,000 or more in value; up to five years in prison on each count of filing false claims for income tax refunds with the IRS; up to 20 years in prison on each count of wire fraud and each count of mail fraud; and mandatory two-year sentences on each count of aggravated identity theft that must run consecutive to whatever sentence may ultimately be handed down. Each count of conviction also carries a fine of up to $250,000.
I hope they find Mr. Ealy soon and lock him up for a very long time. Unfortunately, he is one of countless fraudsters perpetrating this costly and disruptive form of identity theft. In 2014, both my sister and I were the victims of tax ID theft, learning that unknown fraudsters had already filed tax refunds in our names when we each filed our taxes with the IRS.
I would advise all U.S. readers to request a tax filing PIN from the IRS (sadly, it turns out that I applied for mine in Feburary, only days after the thieves filed my tax return). If approved, the PIN is required on any tax return filed for that consumer before a return can be accepted. To start the process of applying for a tax return PIN from the IRS, check out the steps at this link. You will almost certainly need to file an IRS form 14039 (PDF), and provide scanned or photocopied records, such a drivers license or passport.
To read more about other ID thieves who were customers of Superget.info that the Secret Service has nabbed and put on trial, check out the stories in this series. Ealy’s account on Twitter is an also an eye-opener.
Alicia Squires, Manager, Global Certifications Team, Cisco
Ashit Vora, Lab Director and Co-Fonder, Acumen Security
When you're evaluating entropy your process has to be scalable, repeatable and comprehensive... well, comprehensive in a way that doesn't outweigh the assurance level you're going for. Ideally, the method used for the evaluation would be valid for FIPS-140 and Common Criteria.
Could we have the concept of a "module" certificate for entropy sources?
Let's think about the process for how we'd get here. we'd have to look at the Entropy Source: covering min-entropy estimation, review of built-in health tests, built-in oversampling, and a high-level design review.
There are several schemes that cover entropy and how to test it. You need to have a well documented description of the entropy source design, and leverage tools for providing statistical analysis of raw entropy. It would be good to add statistical testing and heuristic analysis - but will vendors have the expertise to do this correctly?
How do you test for this? First, you have to collect from raw entropy - disabling all of the conditioners (no hashing, LFSR, etc) - not always possible, as many chips also do the conditioning, so you cannot get the raw entropy. If you can't get the raw entropy, then it's not worth testing - as long as you've got good conditioning, it will look like good entropy.
In order to run this test, you need to have at least one file of entropy contiaing 1 million symbols and the file has to be in binary format.
When it comes time to look at the results, the main metric is min-entropy.
You need to be careful, though, to not over sample from your entropy source and drain it. You need to be aware of how much entropy it can provide and use it appropriately. [* Not sure if I caught this correctly, as what I heard and saw didn't quite sync, and the slide moved away too quickly]
When it comes to reviewing noise source health test - need to catch catastrophic errors and reductions in entropy quality This is your first line of defense against side channel attacks. This may be implemented in software pre-DRBG or built-in to source.
Ideally, these entropy generators could have their own certificate, so that 3rd parties could use someone else's hardware for an entropy source - w/out having to worry difficult vendor NDA issues.
Random vlues ae required for applications using cryptography (such as for crypto keys, nonces, etc)
There are two basic strategies for generating random bits - non deterministic random bit generator (NDRBG) and deterministic random bit generator (DRBG) . Both strategies depend on unpredictability.
Entropy source is covered in NIST SP 800-90B (design and testing requirements). Entropy source model: Noise source, conditioning component, and health tests.
How do we measure entropy? A noise source sample represents a discrete random variable. There are several measures of entropy based on a random variable's probability distribution line Shannon Entropy or Min-Entropy. NIST SP 800-90B specifies requirements using min-entropy (conservative estimate that facilitates entropy estimation).
FIPS has additional implications for RNG in their implementation guidance, specifically IG 7.11. It defines non-deterministic random number generators (NDRNG), identifies FIPS 140 requirements for tests, etc.
IG 7.13 covers cryptographic key strength modified by an entropy estimate For example, the entropy has to have at least 112 bits of security strength or the associated algorithm and key shall not be used in the approved mode of operation.
But the basic problem - entropy standards and test methods do not yet exist. How can a vendor determine and document estimate of their entropy? How do we back up our claims?
There are also different concerns to consider if you are using an internal (to your boundary) source of entropy or an external (to your boundary) source for entropy.
FIS 140-2 and its Annexes do not cover protocol security, but the goal of this standard (and the organizations controlling it) is to provide better crypto implementations. If the protocol around the crypto has issues, your crypto cannot protect you.
Mr. Nieto's problematic protocol example is TLS - he showed us a slide with just the vulns of the last 5 years... it ran off of the page (and the font was not that large....).
One of the issues is the complexity of the protocol. From a cryptographer's point of view, it's simple: RSA key transport or signed Diffie -Hellman + encryption. In reality, it's a huge collection of RFCs that is difficult to put together.
TLS/SSL has been around since 1995, with major revisions every few years (TLS 1.3 is currently in draft). The basics of TLS are a handshake protocol and a record layer. Sounds simple, but there are so many moving parts. Key exchange + Signature + Encryption + MAC... and all of those have many possible options. When you combine all of those permutations, you end up with a horrifyingly long and complicated list (entertainingly cramped slide results) .:)
But where are the vulnerabities showing up? Answer: everywhere (another hilarious slide ensues). Negotiation protocol, applications, libraries, key exchange, etc... all the places.
Many of the TLS/SSL cipher suites contain primitives that are vulnerable to a cryptanalytic attacks that re not allowed by FIPS 140-2, like DES, MD5, SHA1 (for signing), RC2, RC4, GOST, SkipJack.....
The RSA key transport is happening with RSA PKCS#1 v 1.5 - but that's not allowed by FIPS 140-2, except for key transport. (See Bleichbaker 1998).
There are mitigations for the Bleichbaker, but as of this summer's USENIX Security conf... not great anymore. So, really, do not use static RSA transport (as proposed in TLS 1.3 draft). Recommendation: FIPS 140 should not allow PKCS#1 v 1.5 for key transport. People should use RSA-OAEP for key transport (which is already approved).
Implementation issues, such as a predictable IV in AES-CBC mode, can expose plaintext recovery attacks. When the protocol is updated to mitigate, such as the fix in TLS 1.1/1.2 for Vaudanay's (2002) padding oracle attack, often something else comes along to take advantage of the fix (Lucky 13, a timing based attack).
Sometimes FIPS 140-2 just can't help us - for example, with he POODLE (2014) attack on SSL 3.0 (mitigation: disable SSL 3.0), FIPS 140-2 wouldn't have helped. Authenticated encryption protocols are out of scope. Compression attacks like CRIME(2012)? Out of scope for FIPS 140-2.
Since Heartbleed, the CMVP has started asking labs to test known vulnerabilities. But, perhaps CMVP should address other well-known vulns?
Alas, most vulnerabilities occur outside of the cryptographic boundayr of the module, so it is out of scope. The bigger the boundary, the more complex testing becomes. FIPS 140-2's implicit assumption that if the crypto primitives are correct, then the protocols will likely be correct is flawed.
Perhaps we need a new approach for validation of cryptography that includes approved protocols and protocol testing?
In my personal opinion, I would like to see some of that expanded - but WITHOUT including the protocols in the boundary. As FIPS 140-2 does not have any concept of flaw remediation, if something like Heartbleed had been inside the boundary (and missed by the testers) - vendors would have found them, but had to break their validation in order to fix it.
(Warning: Mildly naughty stuff ahead)
Some of my favorite new submissions this week:
For Lori's 30th birthday her friends thought it would be cute to get her a "2nd quinceañera" cake - quinceañera being the popular Latin American celebration of a girl's 15th birthday.
Now, Lori's baker may not know how to spell "quinceañera," but darned if she isn't a wiz with Hooked on Phonics:
Go on. Read it aloud.
See, now I want to call up this bakery and order something in Klingon, just to see what I get.
The trouble with naming your child Clint:
Never fear, Faith's clown hat is here!
I know it's not even Thanksgiving yet, but some bakeries are already gearing up for the most politically correct time of the year:
Peace on earth. Goodwill toward non-gender-specific beings.
Oh! But you know what's NOT genderless?
This soccer team's cake:
Q: What's that shooting out from the tip?
A: I dunno, but I do know this:
"He shoots, he scooooores!!"
Thanks to Lori B., Ryan C., Ben W., Lori M., & Amanda M. for a real blast.
I still have the flu, tired and vaguely sick, fever varying between 99 and 100, yet am functional. Way more functional than when I wasn't sick but was having a flare up of joint pain. As I think this over I am undoing some hidden levels of blaming myself and worrying that it's my fault or I am specially wimpy or malingering. It is obviously not my fault and I'm tough as nails.
Also maybe I am just not hit that hard by it since I did have a flu shot.
I went out for an hour to the HRDA office party (figuring not contagious if I've had this for nearly 2 weeks) then home again and to bed.
Tomorrow, beta 11 release (specially extended for a week) And then to pain/insomnia therapy and then I will chill out and have a nap. If i feel up to it will go to stef's party. Then swim on the weekend. If I can work up to 2-3 times a week consistently it will be amazing
The portland work week hotel for 1st week of december has a pool. I am going to resolve NOT to try to go out to dinner with people. if i can last the work week sitting up and paying attention and getting back and forth to the hotel it will be ok. d. is going with me and will just work from the hotel. that is amazingly comforting as I won't be stuck and without help if things go wrong physically. and he is super comforting and good to come home to.
I can't tell right this minute if my ankles are stretchy-good hurt or actually hurt. But i ache al over . the PT today was partly some sort of weird pilates machine . and like 20 miutes of lying there trying to move just my lower abdominal muscles, which I am still not sure actually exist. holy crap that was difficult and exhausting. but awesome.
Music! You've had a week to sample the Best of August, time for September 2013! Yes, you can has.
Sherclop Pones -- Hard Knocks (Griffinilla + Alex Cole) Featuring Cats Milly. Soft rock.
Download (Wav): http://www.mediafire.com/download/1bbq5
or Download (Wav): https://dl.dropboxusercontent.com/u/563
ViricideFilly -- Trophy Wife. EXPLICIT LYRICS. Hip Hop or slow rap I just can't say, dripping acid every step of the way.
Soundcloud (Don't see a download): https://soundcloud.com/viricide-filly/t
ImTheMoon -- A Crystal Heart. Piano. Very reminiscent of Ravel, Gaspard de la Nuit.
Feather -- The Moon Rises. This is Feather's cover of the song by Ponyphonic.
New YouTube channel: http://www.youtube.com/user/featherPONY
Feather's stuff on bandcamp: http://feather-vocals.bandcamp.com/musi
Yoka the Changeling -- Anthropology. A funky remix of AwkwardMarina singing 'Lyra's song", it would fit right in the bar scene from Star Wars. The YouTube vid has been played nearly a quarter of a million times.
Download (instrumental only): http://www.mediafire.com/download/l02fa
K Olsen -- Twilightlicious. Imagine Philip Glass does a hiphop remix of Tara Strong's Twilightlicious. You've got it. Awesome.
Soundcloud (Wav file): https://soundcloud.com/kneslo/twilightl
Randall Easter, NIST, Security Testing Validation and Management Group
Partial Cryptographic AcceleratorsDraft IG 1.9: Hybrid Module is crypto software module that takes advantage of "Security Relevant Components" on a chip.
But, that doesn't cover modern processors like Oracle's SPARC T4 and Intel's AES-NI - so there is a new IG (1.X): Processor Algorithm Accelerators (PAA). If the software module relies on the instructions provided by the PAA (Mathematical construct and not the comlete algorithm as defined in NIST standards), and ccannot act independently - it's still a hybrid. If there are issues with the hardware and the software could work on it's own (or on other platforms), then it is NOT a hybrid. (YAY for clarification!)
Sub-Chip ModulesWhat is this? A complete implementation of a defined cryptograpic module is implemented on part of a chip substrate. This is different than when a partial implemenation of a defined cryptographic module is implemented on part of a chip substrate (see above).
A sub-chip has a logical soft core. The cryptographic module has a contiguous and defined logical boundary with all crypto contained within. Durign physical placement, the crypto gates are scattered. Testing at the logical soft core voundary does not verify correct operation after synthesis and placement.
There are a lot of requirements in play here for these sub-chip modules. There is a physical boundary and a logical boundary. The physical boundary is around a single chip. The logical boundary will represent the collection of physical circuitry that was synthesized from the high level VHDL soft core cryptographic models.
Porting is a bit more difficult here - the soft core cna be re-used, unchanged, and embedded in other single-chip constructs - this requires Operational Regression testing. This can be done at all levels, as long as other requirements are met.
If you have multiple disjoint sub-chip crypto... you can still do this, but it will result in two separate cryptographic modules/boundaries.
What if there are seveal soft cores, and they want to talk to each other? If I have several different disjoint software modules that are both validated and on the same physical device, we allow them to exchange keys in the clear. So, why not? As long as they are being directly transferred, and not outside of the trip through an intermediary.
As chip densities increase, we're going to see more of these cores on one chip.
Why did we come up with IG 9.10 [Power On Self Tests]? There were many open quetions about how software libraries fit into the standard. In particular, CMVP did not allow static libraries - but they existed. We needed to come up with reasons to rationalize our decision, so we could spend time doing things other than ddebating.
Related to this are IG 1.7 (Muliple Approved Modes of Operation) and IG 9.5 (Module Initialization during Power-Up).
The standard is clear in this case - the power-up self tests SHALL be initiated automatically and SHALL not require operator intervention. For a software module implemented as a library, an operator action/intervention is any action taken on the library by an application linking to it.
Let's look a the execution control flow to understand this problem. When the library is loaded by the OS loader, execution control is not with the library UNLESS special provisions are taken. Static libraries are embedded into the object code and behave differently.
How do we instrument a library? Default entry points are well-known mechanism for operator-indeendent transfer of execution control to the library This has been available for over 30 years, and exist for all types of libraries: static, shared, dynamic.
There are alternative instrumentation - in languages like C++, C# and Java you an leverage things like static constructors that are executed automatically upon loading the library containing them when it is loaded.
What if the OS does not provide a DEP mechanism and the module is in a procedural language like C? You can consider switching to C++ or using a a C++ wrapper, so that you can get this functionality. Lucky for my team, Solaris supports _init() functions. :)
Implementation Guidance 9.5 and 9.10 live in harmony - you need to understand and implement both correctly.
Static libraries can now be validated with the new guidance.
Steve (?), CAVP, NIST
The CAVP takes over after NIST picks a new algorithm, the CAVP takes over and figures out how to test it. They need to evaluate the algorithm from top to bottom - identify the mathematical formulas, components, etc.
The CAVP develop and implement the algorithm valdiation test suite. Which requirements are addressable at this level? They develop the test metrics for the algorithm and exercise all mathematical elements of the algorithm. If something fails - why? Is there an error in the algorithm, or an intentional failure - or is there an error in the test?
The next stop is to develop user documentaion and guidance, called validation system document (VS), documents test suite and provides instructions o implementing validation tests. There is cross validation, and make sure that both teams come up with the same answers - a good way to check their own work.
The basic tests are Known Answer Tests (KAT) , Multi-block Message Test (MMT), and Monte Carlo Tests. KATs are designed to verify the components to algorithms. MMT will test algorithms where there may be chaining of information from one block to the next and make sure it still works. The Monte Carlo Tests are exhaustive, checking for flaws in the UI or race conditions.
Additionally need to test the boundaries - what happens if you encrypt the empty string? What if we send in negative inputs?
There are many documents for validation testing - one for each algorithm or algorithm mode.
The goals of all these tests? Cover all the nooks and crannies - prevent hackers from taking advantage of poorly written code.
Currently, the CAVP is working on tests for SP 800-56C, SP 800-132 and SP800-56A (Rev2).
In the future, there will be tests for SP 800-56B (rev1), SP 800-106 and SP800-38A. Which ones of these is more important for you to get these tests completed?
Upcoming algorithms that are still in draft, FIPS 202 (Draft) for SHA3, SP800-90A (Rev2) for DRBG, SP800-90B for Entropy Sources and SP 800-90C for construction of RBGS. Ms. Keller has learned the hard way - her team cannot write tests for algorithms until they are a published standard.
Today is Use Less Stuff Day - a time to push back against rampant materialism, reflect on life goals, and really ask ourselves the tough questions.
Do Snow White and the Dwarves really NEED a helicopter?
I mean, maybe they're Ok with just a monster truck, motorcycle, jeep, Lightning McQueen, and an airplane:
Or if not, Hulk could just throw them really hard.
And while we're cutting back, how many choking hazards do you REALLY need for a one-year-old?
Or for your cupcakes?
And why does Hilary Duff need so many Barbie accessories?
(Hey look, it's the pink boot we all lost when we were six! [No? Just me?])
My point is, why waste so much plastic flotsam when a single, well-placed element can be just as...
That is, I mean, sometimes it only takes ONE to... er...
Well, maybe if we just put our heads together...
Thanks to Mike & Marja, Joyce W., Anony M., Nelly R., Melanie L., Mary V., & Susan S. for showing us how to get a head without paying an arm and a leg.
A tongue in cheek title... of course we're hoping nobody is listening! While Ms. Davidson is not a lobbyist, she does spend time reading a lot of legislation - and tries not to pull out all of her hair.
There are business concerns around this legislation - we have to worry about how we comply, doing it right, etc. Getting it right is very important at Oracle - that's why we don't let our engineers write their own crytpo  - we leverage known good cryptographic libraries. Related to that, validations are critical to show we're doing this right. There should not be exceptions.
Security vulnerabilities... the last 6 months have been exhausting. What is going on? We all are leveraging opensource we think is safe.
We would've loved if we could've said that we knew where all of our OpenSSL libraries were when we heard about Heartbleed. But, we didn't - it took us about 3 weeks to find them all! We all need to do better: better at tracking, better at awareness, better at getting the fixes out.
It could be worse - old source code doesn't go away, it just becomes unsupportable. Nobody's customer wants to hear, "Sorry, we can't patch your system because that software is so old."
Most frustrating? Everyone is too excited to tell the world about the vulnerability they found - it doesn't give vendors time to address this before EVERYONE knows how to attack the vulnerability. Please use responsible disclosure.
This isn't religion - this is a business problem! We need reliable and responsible disclosures. We need to have good patching processes in place in advance so we are prepared.We need our opensource code analyzed - don't assume there's "a thousand eyes" looking at it.
Ms. Davidson joked about her ethical hacking team. What does that mean? When they hack into our payroll system, they can only change her title - not her pay scale. How do you think she got to be CSO? ;-)
Customers are too hesitant to upgrade - but newer really is better! We are smarter now than we used to be, and sorry we just cannot patch you thousand year old system. We can't - you need to upgrade! The algorithms are better, the software is more secure - we've learned and you need to upgrade to reap those benefits.
But we need everyone to work with us - we cannot have software sitting in someone's queue for 6 months (or more) to get our validation done. That diminishes our value of return - 6 months is a large chunk of a product's life cycle. Customers are stuck on these old versions of software, waiting for our new software to get its gold star. Six weeks? Sure - we can do that. Six months? No.
Ms. Davidson is not a lobbyist, but she's willing to go to Capital Hill to get more money for NIST. Time has real money value. How do we fix this?
What's a moral hazard? Think about the housing market - people were making bad investments, buying houses they couldn't afford to try to flip houses and it didn't work out. We rewarded those people, but not those who bought what they could afford (or didn't buy at all) - we rewarded their bad risk taking.
Can we talk with each other? NIST says "poTAHto", NIAP says "poTAHto" - why aren't they talking? FIPS 140-2 requires Common Criteria validations for the underlying OS for higher levels of validations - but NIAP said they don't want to do validations
We need consistency in order to do our jobs. Running around trying to satisfy the Nights Who Say Ni is not a good use of time.
And... The entropy of ... entropy requirements. These are not specific, this is not "I know it when I see it". And why is NIAP getting into entropy business? That's the realm of NIST/FIPS.
Ms. Davidson ends with a modest proposal: Don't outsource your core mission. Consultants are not neutral - and she's disturbed by all of the consultants she's seeing on The Hill. They are not neutral - they will act in their own economic interest. How many times can they charge you for coming back and asking for clarification? Be aware of that.
She also requests that we promote the private-public partnership. We need to figure out what the government is actually worried about - how is telling them the names of every individual that worked on code help with their mission? It's a great onus on business, and we're international companies - other countries won't like us sharing data about their citizens. Think about what we're trying to accomplish, and what is feasible for business to handle.
Finally, let's have "one security world order" - this is so much better than the Balkanization of security. This ISO standard (ISO 19790) is a step in the right direction. Let's work together on the right solutions.
 Unless you're one of the teams at Oracle, like mine, who's job it is to write the cryptographic libraries for use by the rest of the organization. But even then, we do NOT invent our own algorithms. That would just be plain silly.
Illusions can be fun ... if we know they are an illusion. They can make us feel good... even if they are bad. They can make us think something is okay... when it's really broken.
There are some illusions we like in technology, like virtualization! The illusion is that we have more resources than we really have. We can save money - that's good, right? Some people think that virtualization provides more security - but does it really? Vendors claim their virtualized systems are just like a real hardware box... but are they? Often not exactly. Something has to give, we should understand this.
How is entropy impacted once you virtualized the system? Virtualizaion can change the timing, it may just behave differently. Either way, are we getting the same entropy on these systems?
Often, we make incorrect assumptions about things like timing and the similarity of a virtualized system to its true hardware counterpart.
For example, if you're using time as your entropy source - you may assume the lowest order bits are changing most frequently and will provide more actual entropy. But, what if this is not the true timer? What if a hypervisor is intercepting and interpreting the concept of "time" - what if the hypervisor should not be trusted?
Shouldn't you be able to trust your hypervisor? Once someone has breached the hypervisor, they can do all kinds of evil things underneath your VM and you won't be able to easily detect it (as your OS will be unchanged).
For example, the RDRAND instruction can be intercepted by a hypervisor. This is a "feature" documented by Intel. So, as a user of the VM, you think you're getting some pretty good entropy from RDRAND - but you're really getting poor entropy from your hypervisor. How could you detect this? Intel's RDRAND is often used as the sole source of randomness with no DRNG postprocessing (like in OpenSSL), regardless if the "randomness" is being used for generating nonces or for generating cryptographic key material.
Assuming a compromised hypervisor, the bad guy can have the key used to generate the "random" sequences used in the RDRAND emulation. He can use this to generate the different random streams. He is able to get the nonce, which is transmitted in the clear.
Launching the attack requires installation of a hypervisor or the modification of a running hypervisor. Just one flaw that allows the execution of privileged code is all it takes. The hacker, this this case, may have the session key even before the communicating parties have it! At this point, it doesn't matter what algorithm you're using - communications are essentially in the clear.
This attack is not that easy - it requires taking over the hypervisor (not easy), and once you have the hypervisor, you can do anything you want! But, this isn't about taking down the machine, this is about eavesdropping undetected for any length of time.
This is a sneaky attack - virus scanner and host-based IDS will tell you everything is okey dokey! It is independent of the OS or ay applications (as many rely on RDRAND) .
How can you protect yourself? The basic solution is diversification - do not use a single source of entropy. Use a different RNG for nonce generation and generation of key material, and use RDRAND for seeding (with other sources) rather than directly for generating critical security parameters. Read the hardware documentation carefully - make sure you understand what you're getting.
Intel isn't going to fix this, as this isn't a bug... it's a feature!
Entropy analysis isn't just about the mathematical entropy analysis - be aware of how you procure the numbers and how they are used in your system.
As a side note, we (in Solaris land) are aware that this is a tough problem and hard to get right and we've already implemented counter measures. Darren Moffat did a great write up on Solaris randomness and how we use it in the Solaris Cryptographic Framework, describing the counter measures we already have in place.
(If you want that body detail, though, I'd try some gold puff paint.)
[Alternate: Instead of foil & spray adhesive, you can also substitute metal tape.]
Alternate: Since some of you just reminded me it's FREEZING where most of you are, you can easily substitute metal tape for the tin foil & spray adhesive. The tape may gum up your scissors a bit, so just have a rag on hand to clean off the adhesive every few slices.
FIPS 140-2 doesn't talk much about the algorithms themselves, they are covered in the Annexes. There were minor changes back in 2002/2003, however the algorithms have changed. New algorithms have come in, old ones have been deprecated.
Under the ISO rules, every country can choose their own algorithms. In the US, we've already chosen our algorithms for FIPS 140-2. We'll likely continue to use the same ones in FIPS 140-4 (or whatever we call them).
The current major algorithm documents are SP 800-131A and FIPS 186-4. The stronger key requirements went into effect last year and there is a major hit coming in at the end of 2015.
Why are we doing this transition? Security strenght of 80 bits is insufficient (the 56-bit strong DES was broken long ago; attacks on the SHA-1 collision resistance property; advances in integer factorization; etc). Some of the currently approved algorithms aren't strong regardless of the key length (the non SP-800-90A RNGs). Transition plans were fist announced in SP 800-57, Part 1 in 2005. We've delayed this from going into effect from 2010 to 2015, but cannot delay it further or we'll be hurting the consumers.
Approved are the best algorithms. Deprecated algorithms are not recommended, but can be used. This is different than restricted, which you should not use. Legacy use have no guarantee, but really should not be used, except to verify previously generated signatures, for example. Some algorithms are just simply not allowed.
For example, SKIPJACK decryption was allowed at the end of 2010 for legacy use only, but SKIPJACK encryption is disallowed. Only 8 certificates were ever issued, so there were not any complaints bout this change.
At the end of 2010, two-key 3DES encyrption is restricted (100 bits of strength for two-key 3DES with no more than 3^20 (plantext, cyphertext) pairs), two-key 3DES decryption is legacy-use only.
At the end of 2015, two-key 3DES encryption is disallowed. AES and three-key 3DES are acceptable. We allowed this for so long, because it was in wide use and the attacks were not straight forward.
Digital SignaturesAs of the end of 2010, signature generation algorithms with less than 112 bits of encryption strenght became deprecated. As of the end of 2013, there was a transition from FIPS 186-2 to FIPS 186-4 and signature generation algorithms with less than 112 bits of cryptographic strength became disallowed.
Signature verification with less than 112 bits of strength is legacy-use, beginning in 2011.
Deterministic Random Number GeneratorsThis is the BIG problem! As of the end of 2010, te non-SP-800-90A compliant RNGs became deprecated. As of the endof 2015, the non-SP-800-90A compliant RNGs will become disallowed. As of the end of 2015, the non-SP-800-90A complaint RNGs became disallowed - RETROACTIVELY! This will be a big expense, as previously purchased software can no longer be used.
Note from Randy Easter: What this means is that every validation that was done over the last 15 years and every validation that is not using this RNG, that item will be moved to the nonapproved line. If the keying algorithm is using this RNG, ALL of those functions become non approved.
Key Agreement and Key TransportAs of the end of 2013, Key Agreement and Key Transport algorithms stay acceptable if: key strength is at least 112 bits AND the algorithms are compliant with the appropriate NIST standards: SP 800-56A, SP 800-56B and SP 800-38F. As of the end of 2013, the non-compliant Key Agreement and Key Transport (Key Encapsulation) algorithms have become deprecated if key strength is at least 112 bits. Key wrapping must be complaint with one of the provisions of SP 800-38F. Everything else is disallowed.
OthersHash and MAC functions will be impacted, as well as some key derivation algorithms. See SP 800-131A for details
FIPS 186-2 to 186-4 TransitionBeginning in 2014, new implementations shall be tested for their compliance with FIPS 186-4. This applies to domain parameter generation, key pair generation and digital signature generation. Signature verification per FIPS 186-2 is Legacy-use. Beginning this year (2014), RSA digital signature keys must be generated as shown in FIPS 186-4.
Future Transition PlansYou bet - already looking forward to the future. We want to transition away from non-Approved implementations of key agreement (DLC-based) and key transport (RSA-based) schemes. Unfortunately, there are too many modules in existence that are non compliant with SP 800-56A and 56B. We need a well thought out strategy for transition.
Randall Easter, NIST, Security Testing, Validation and Management Group
Allen Roginsky, Mathematician, NIST
Sharon Keller, Director, Cryptographic Algorithm Validation Program (CAVP), NIST
This panel is entirely questions and answers. I'll do my best to capture them.
Q: About bug fixing and patches. Is there an expedited way, once we get our validation, if there's a non security patch, is there a non-painful/easy way for us to update the validation?
A: Randy: Yes, we have a process, but whether it's painless or not... Even if the changes are not security relevant, you will have to go back to the lab. They will decide if it is security relevant or not, and they can do an electronic submission to NIST. It may require re-doing your algorithm testing and updating your certificate. If there are no issues, we can usually do the update within a week - once we get the paperwork from the lab.
Q: What happens with a datacenter that is always doing critical functions, it can never give up. How can they do more tests?
A: Randy: If there is critical work being done, this can be deferred until the next time period. It doesn't say "after 42 deferrals you have to interrupt work". There may be time when the processor is doing non crypto, then the checks can be run. The processor, in my experience, is not 100% busy on crypto.
Q: So, it can be indefinite?
A: Randy: Yes.
Q: Will CAVP now be testing and verifying all of the SHALL statements? Or is that a documentation thing?
A: Sharon: CAVP tests all the things that are testable. Back in the day, they all just gave tests for the algorithm - but then things got more complicated, like making sure vulnerabilities aren't introduced. For example, it's a good thing if the IV is never repeated, but that thing is not testable.
Randy: One good example is 800-90A. There are quite a bit of SHALLs in there, but there are some things that are difficult to test, so thing fall through the cracks.
Q: In CC, we have the concept of Flaw Remediation. There are sometimes fixes we can make judegement calls ourselve. The time and money it costs to go back to the lab for FIPS makes it prohibitive for us to maintain validation
A: Randy: I can't speak to CC, but once you open the box to make changes, then we need the lab to validate you only changed what you said you changed. Not every change has to be revalidated, there can be judgment there. This has been the policy in CMVP since 1995, every change has to be verified by the lab. My experience in development, it's possible to think you've only made a small change, only later discover that it had unforeseen consequences.
A: Moderator: Working at a lab that does CC, there are vendors that abuse Flaw Remediation.
[VAF: Note: who better to judge how relevant a change is, than the developers who are intimately familiar with the codebase?]
Q: Is there a rough estimate when ISO 19790 will be adopted?
A: Randy: I honestly do not know. Hopefully mid next year, but just don't know. There will be a transition date from FIPS 140-2. But we don't know how long that will be. In the past, it was a 6 month transition period, but depending how this goes - we may need more time?
Q: Given the last public review of FIPS 140-3 was more than 5 years ago, are you ready to go forward with this standard?
A: Carolyn: This is a different process. The ISO process is different. They don't have that type of review.
Randy: We could have a review of sorts about whether or not we want to move to the ISO standard. We won't pick up the old FIPS 140-3, as there are no DTRs and there won't be. The only path forward is with ISO 19790.
Q: Randy mentioned earlier that we'll still have Implementation Guidance. The current IGs are getting very large and difficult to navigate. How will this work with an international standard?
A: Randy: We work with Canada already and have a non-binding agreement with the Japanese guidance. We circulate the guidance with the labs before we post. The guidance is big, because we've been using FIPS 140-2 for nearly 13 years. It's only large because time has gone on for so long. As the program has grown, the vendors and the users have gotten more sophisticated and therefor require particular guidance to address. Hopefully we'll refresh more often and be able to better manage this.
Q: If I went down the ISO road right now, and in 18 months from now I'm ready to validate - but the new standard hasn't been adopted, yet, I won't pass FIPS 140-2, will I?
A: Randy: That's right. You could get this validated by JCVP, but the US doesn't recognize this standard at this time. We would like a decision to get made. Yes, I said that last year, too.
Q: Elliptic Curve Cryptography has come up significantly over the last year, particularly around NSA Suite B. Do you have plans to standardize any other curves that did not come from the NSA?
A: Allen: I am not aware of any work in this area. I am not aware of any weaknesses in the current curves. In general, one is good enough, the strength is not in the curve (as long as it meats the requirements) - the strength is in the key. Some are over the binary fields, some are over the primary fields. You can choose one or the other. One problem with ECC is with the DUAL ECDRBG algorithm. The problem is not with EC, but is in this particular algorithm. There was a guard in EC to protect against this, but you can't stop a problematic implementation or use. There are no known issues with the existing curves.
Q: Our hardware now has partial implementations of crypto algorithms. We have software that can do the rest and work on the older processors, so it doesn't require the hardware but will use it if it's there.
A: Carolyn: If it can do everything in software, it's not a hybrid module.
Q: We had anticipated RSA 4096 being approved, but now it isn't.
A: Allen: It has been in FIPS 186-2, but it is no longer there. It is not allowed now for signature generation. The reason is to facilitate the transition to EC. It's very difficult to be sure that all of the floating point arithmetic is done correctly when you're dealing with these numbers. It can be done, but it's error prone. The decision was made to move to technology where the keys are shorter, like in EC. Some people have complained about this, but this is the decision. I think it's the correct one.
Q: Do you know of anything in the ISO standard that will impact current validations?
A: Randy: There is nothing that is retroactive. Existing validations should stand. New modules, though, will have to meet the new requirements once it's in place.
Q: ISO being international, but you haven't mentioned CAVS. There's no requirement that they are international.
A: Randy: It's an international standard, but CAVP will still be a US program. We'll be using an international standard. We're working on an ISO standard on how to do algorithm testing.
ISO/IEC 19790:2012 is the planned replacement for FIPS 140-2, but there's been no official announcement or timeframe, yet. This means no labs are accredited to perform these validations.
But... it's coming.
Some of this will be a rehash of our earlier sessions, but with more deep diving per section.
Degraded OperationThis mode can only be used after exiting an error state and must be able to provide information about this state. Whatever mechanism or function is causing the failure shall be isolated. While in the degraded mode, all conditional algorithm self-tests shall be performed prior to the first operational use of the algorithm and before degradation can be removed, all tests must pass
Cryptographic Module InterfaceThe cryptographic module interface is a fifth logical interface that cannot be used whenever you're in an error state.
Roles, Services and AuthenticationThe user role is optional, there is a minimum requirement of a crypto-officer role. The minimal service requires showing the module's versioning info that matches the certificate on record.
There is also a new requirement for self-initiated cryptographic output capability.
Authentication strength requirements must be met by the module's implementation, not through policy controls or security rules. For example, password size restrictions. ISO 19790 does not yet define what exactly those strength requirements are. Level 4 modules will have to implement multi-factor authentication.
Software/Firmware SecurityThis section of the document applies only to software/firmware or hardware modules. Level 2 modules must implement an approved digital signature or keyed MAC for integrity test, Levels 3 & 4 have higher requirements.
Operational EnvironmentSoftware modules no longer need to operate in Common Criteria (CC) evlauted OS or "trusted operating system in order to meet Level 2 requirements. There are specific OS requirements still required to meet Levels 2-4 (that will look similar to what used to be covered by CC).
Physical SecurityExplicitly allows translucent enclosers/cases, in addition to FIPS 140-2 allowed opaque enclosures/cases, within the visible spectrum. Level 3 modules must either implement environmental failure protection (EFP) or undergo environmental failure testing (EFT). Level 4 MUST implement EFP.
Non-Invasive SecurityThis section currently doesn't specify requirements, but they will come. Hardware and firmware must comply and it will be optional for software For levels 1-2, module must protect against these attacks. Level 3-4 will have to prove protection.
Sensitive Security Parameter (SSP) ManagementSSPs consists of Critical Security Parameters (CPSs) and Public Security Parameters (PSPs). For Level 2 modules and up, procedural zeroization is not allowed.
Self TestsThere are two categories of self-test: Pre-operational and conditional. Pre-operational includes things like integrity test and critical functions test. Conditional covers the other standard conditional tests plus the other items covered in the old POST guidance.
All self-tests need to be run regardless of if module is operating in approved or non-approved mode. Level 3 & 4 modules must include an error log that is acceisble by an authorized operator of the module. Integrity test needs to be run over all software/firmware components of module. At a minimum, vendor must implement one cryptographic algorithm self-test as a pre-operational test.
[Clarification from Randall Easter on this topic: If the module is installed and configured as a FIPS 140 module, then it must do all of these tests/checks. If it was installed and configured otherwise, it's not required. This is not different than what is currently required by FIPS 140-2.]
FIPS CRNGT is not currently defined in ISO.
ISO 1970 requires Level 3 & 4 modules to do automatic pre-operational self-tests at a predefined (by vendor) interval.
Life-Cycle AssuranceThis seems to be more of a documentation and QE section. Covers vendor testing and finite state model. The states required are: General Initialization State, User State, and Approved State. Changing to crypto-officer from any other role is prohibited.
Testing Requirements for Cryptographic ModulesThe next part of the talk came from Zhiqiang (Richard) Wang, Leidos, Senior Security Engineer.
The testing requirements were derived from the FIPS 140-2 derived testing requirements. This covers self-tests, live cycle assurance and mitigation of other attacks.
ISO/IEC 24759:2014 specified shte methods to be used by testing laboratories to test whether the cryptographic module conforms to the requiremetns speified in ISO/IEC 19790:2012. This was developed to provide a high degree of objectivity during the testing proess and to ensure consistency across the testing laboratories. It clearly specifies what the vendor needs to provide to the laboratory.
Richard spent time walking through section by section going through many of the same requirements discussed early, but with a twist on how it would be tested or why.
ISO 19790 is available for purchase from ISO (in Swiss Francs) or ANSI (US Dollars), and you'll also need the derived test requirements (ISO/IEC 24759) .
In this section, Randy walked us through a deep dive of the sections of the document.
There is a new Terms and Definitions section, which will hopefully help to clear up ambiguity and help answer a lot of the questions they've gotten over the years.
The new document has all of the SHALL statements highlighted in red, with [xx.yy] - where xx indicates the clause and yy is anumeric index within the clause. This will make it, hopefully, easier for two people to have a conversation about the standard. The plan is, when errors are found and fixed with addenda, there will be complete new revisions of the document available - ie everything in one place.
Errors were found during translations to Korean and Japanese, when the translators just could not figure out what something was supposed to me (turns out, it wasn't clear in English, either). We should expect more changes as people start to implement against this standard. Errors will be corrected again in revisions. Mr. Easter was not clear what ANSI/ISO charge for revisions of documents.
There will be four levels for validation again. The requirements vary greatly for physical security between the levels, from "production grade components" to "tamper detection and response envelop, EFP and fault injections mitigation". You will still need environmental controls for protecting key access, etc.
There are algorithms like Camelia that the US Federal Government are not allowed to use, but vendors are designing software for international markets. So, federal users can only use certain algorithms - the vendors do NOT have to restrict this, it is up to the end user to implement and use the policy correctly. How do you audit that, though?
ISO standard states that every service has to have a "bit" that tells whether or not it's an approved service or not. This should enable this to be better audited.
This is a great policy, but what happens when you have to work what you get? For example, someone could send the IRS a tax return encrypted with RC4. The IRS can decrypt using RC4, but would have to store using AES. It would be good to know what has happened here.
The new ISO standard has requirements around roles, services and authentication. The minimum role is the crypto officer - there has to be logical separation of required and optional roles and services. The higher up the the levels go, the more restrictions: like role-based or identity based authentication all the way up to multi-factor authentication.
There's been a lot of questions about FIPS 140-2 about what we mean by "list all the services". Does that mean only all the approved services? No, all services - even non approved security functions. Non security relevant services also have to be listed, but that can refer to a separate document. [VAF: curious still, what exactly that means - an OS provides a LOT of services!]
ISO 19790 has new directives of managing sensitive security parameters - for example, you have to provide a method to zeroize keys. This could be done procedurally by an operator, or as a result of tamper. Other examples this area covers: random bit generation, SSP generation, entry, output and storage of keys.
Self-tests have changed. Pre-operational tests cover software/firmware integrity, bypass and critical functions tests. Crypto operations can begin to proceed while these tests are running, but the output cannot be provided until the pre-operational tests have completed.
Known answer tests are now all conditional tests, like pair-wise consistency checks. Vendors can continue to do all of the tests up front, or as needed. Lots of flexibility here. Mr. Easter made a note I couldn't quite follow about module updates being signed by the crypto officer - not clear why it wouldn't be the vendor. [VAF: I may have missed something here.]
The new standard still allows simulation environments for testing, and special interfaces for the labs to test against that may not be needed by the consumer.
Surprising to NIST, some consumers don't care about FIPS 140 validations and the vendors want to provide that to them. For example, some of the tamper evident seals may need to be installed by the cryptographic operator, or some initialization procedures. Some customers may not even care about power-on-self-tests EVER being run, so that configuration information has to be part of the integrity check.
As a note: some of the current FIPS 140-2 implementation guidance will be retained with this new standard, as they are newer than the ISO standard, or too vendor specific to be included in a general document.
The vendor may have mitigation against some attacks that there are no currently testable requirements available, and that would be allowable through Level 3. Once you get to Level 4, you have to prove your mitigations.
The new standard allows for degraded modes of operation - for example, if one algorithm stopped functioning properly the rest of the algorithms could still be used.
Something new: here has to be a way to validate that you're running a validated version and what the version number is. This is interesting and tricky, because of course you get your validation done on released software, so when you ship you don't know that you're validated. And if you store validation status in another file, it could easily get out of date (ie updates done to the system, but software still reporting it's validated). There are ways to solve this, but vendors should tread carefully.
Also, Annex C (and only Annex C) which covers approved security functions (ie algorithms) can be replaced by other countries, as needed.
Q: "How does software have an 'opaque' coating?" A: "Physical security requirements do not have to be met by software modules".
Q: "Lots of services could be going on, what do we need to be concerned with" A: "Services that are exposed by the module, via command line or API. Security services need be be queryable".
Q: "Why should the crypto officer be signing new modules? They may not be able to modify the trust anchors". A: Was using crypto officer as an example, policies could vary - but it is the crypto officer's decision on what to load.