Podcast for 24 August 2015

Started by MrBogosity, August 23, 2015, 06:00:00 PM

Previous topic - Next topic
[mp3]http://podcast.bogosity.tv/mp3s/BogosityPodcast-2015-08-24.mp3[/mp3]


Co-Host: Charles Thomas

News of the Bogus:
30:58 - Biggest Bogon Emitter: The Swedish Federation for Lesbian, Gay, Bisexual and Transgender Rights http://www.blazingcatfur.ca/2015/07/21/sweden-democrats-plan-gay-pride-parade-through-muslim-areas-leftists-and-gay-rights-groups-decry-the-parade-as-racist/

37:13 - Idiot Extraordinaire: Richard Blech http://krebsonsecurity.com/2015/08/how-not-to-start-an-encryption-company/

This Week's Quote: "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." —Bruce Schneier

It's weird how they're reporting that in pounds
Working every day to expose the terrible price we pay for government.

Here's the report where that 500 million BPS figure comes from:

http://forbritain.org/propagandapaper.pdf
Working every day to expose the terrible price we pay for government.

Quote from: Dallas Wildman on August 23, 2015, 06:51:58 PM
It's weird how they're reporting that in pounds

Why is it weird? They're British!

The MPAA didn't learn anything from the CSS fiasco, either.  The AACS system used in Blu-Ray disks has been defeated in several ways, including methods that have defeated the key distribution mechanism (BEFORE official launch of the system, we knew about this when I was at Dell in late 2006), permanently defeating it.

The problem with DRM is, it's doomed from the word "go." Ecryption absolutely depends on keeping the keys necessary to decrypt the content secret. But digital media MUST be decrypted to be viewed. So it absolutely depends on the players having the decryption keys--which means giving the customer access to them.

No way around it.

Quote from: MrBogosity on August 24, 2015, 02:10:54 PM
The problem with DRM is, it's doomed from the word "go." Ecryption absolutely depends on keeping the keys necessary to decrypt the content secret. But digital media MUST be decrypted to be viewed. So it absolutely depends on the players having the decryption keys--which means giving the customer access to them.

No way around it.

I'm quite certain they thought they got around that with requiring a run-time environment provided by the disk to check the player's security, but that depends on the player telling the truth to the software, which is obviously not something it can verify unless the player DOES tell it the truth.

I recall how everyone immediately spotted the problem with the (so far as I know, still unused) system to block 'insecure' display paths for underaged picture and sound.  All you need to do is grab the chipset from a valid destination device and use that to fake out the source device.  All it takes is a junked anything with an HDMI input, and some electronics skills.  Maybe not for everyone, but pretty trivial for the professionals.

Then there's the silly idea of watermarking the physical media so that non-compromised players won't play pressed disks without it.  That'll stay out of the hands of pirates right up until you ship the device that does the watermarking, which essentially delivers the devices to the pirates.  (There's no plausible way to NOT ship them through places like the South China Sea, where not only do pirates regularly capture cargo vessels, they often run them themselves for a while, even under real, if purchased, registrations.  If it really was a big enough problem, then someone in the underworld would commission the specific theft of the watermarking devices.)

This is what happens when you let LAWYERS design the system.  Look at how bad DIVX disks crashed and burned.  (As soon as I read about those, I realized they forgot to include any way for the people who distribute the damn things to make any money off them.  Instant product failure, right there, since nobody will sell them.)

Quote from: MrBogosity on August 24, 2015, 08:42:55 AM
Why is it weird? They're British!

The authors of the report, yes.  Oh yeah, it's from the Telegraph.  Nevermind
Working every day to expose the terrible price we pay for government.

August 25, 2015, 07:12:22 AM #8 Last Edit: August 25, 2015, 08:10:02 AM by MrBogosity
Quote from: evensgrey on August 24, 2015, 05:26:45 PM
I'm quite certain they thought they got around that with requiring a run-time environment provided by the disk to check the player's security, but that depends on the player telling the truth to the software, which is obviously not something it can verify unless the player DOES tell it the truth.

And that's really the crux of it: you're relying on something on the localhost to keep the keys private, but that means "hiding" it in plain sight.

Ironically, I'm seeing another manifestation of the problem now: I'm in a discussion group for the design of a new technology that hopefully will make passwords completely obsolete (more on that when it's ready, hopefully RSN), and there's an issue of how you get the browser to talk securely to the client software that operates your identity. The idea was to make the client operate as its own web server which doesn't need to be TLS (since localhost connections happen at the kernel level, only a rootkit would expose them to an attacker), but ANY non-secure connection--even to localhost--breaks the security model and turns the website's nice, green EV certificate you paid a lot of money for into that grey lock with the yellow warning triangle. We could put TLS on the client and make the localhost connection secure, but the client wouldn't be able to use self-signed certs for the same reason, so it would need to be trusted by a CA, which would also have to be local.

But CAs have to keep their private keys private, when they couldn't since it's on the localhost!

It sucks, because otherwise this would COMPLETELY rule out the possibility of MITM attacks!

Security is HARD.

Quote from: MrBogosity on August 25, 2015, 07:12:22 AM
Security is HARD.

And there's the REAL crux of the problem.  This is why all non-open security systems are ultimately doomed:  The problem is so hard that no approach that reduces the number of eyes that can look for flaws has any chance of working out.

Look at the idiocy that chip-and-PIN has produced:  The PUBLIC part of the specification, which is completely inadequate to implement it, runs to over a thousand pages.  Even without a whole lot of required info to implement it, at least one MITM attack has already been demonstrated for banks that don't implement it correctly in a place that's really easy to get wrong.

The chip-and-PIN MITM attack exploits the fact that the system doesn't necessarily force an end-to-end verification of all communications between bank and card, despite the obvious need to do so to prevent MITM attacks.  This allows flawed implementations to be spoofed with a fake card connected to a real card through a smart interface such that the bank thinks the card verified the PIN, while the card thinks the PIN wasn't required.

Quote from: evensgrey on August 25, 2015, 02:24:09 PM
And there's the REAL crux of the problem.  This is why all non-open security systems are ultimately doomed:  The problem is so hard that no approach that reduces the number of eyes that can look for flaws has any chance of working out.

Well, as we've seen this year with OpenSSL and BASH, Open Source is absolutely no guarantee. With security problems hanging around for DECADES without being discovered, I think proprietary software that's been independently audited (like LastPass) beats Open Source, unless you know of a proper security audit for it.

QuoteThe chip-and-PIN MITM attack exploits the fact that the system doesn't necessarily force an end-to-end verification of all communications between bank and card

Which any security audit would have found and given a failing grade for that reason.

On a different topic, deaths are being linked to the Ashley Madison hack.  Yesterday, police investigating the matter were saying two suicides had already been connected to it.  Given the sheer scale of the breach, it isn't plausible that anyone could think there wouldn't be some people affected who would be pushed over the edge by this.

Quote from: evensgrey on August 26, 2015, 08:03:23 AM
On a different topic, deaths are being linked to the Ashley Madison hack.  Yesterday, police investigating the matter were saying two suicides had already been connected to it.  Given the sheer scale of the breach, it isn't plausible that anyone could think there wouldn't be some people affected who would be pushed over the edge by this.

It's possible, but do we know that for a fact? Or is it just that they were in the database? Of the MILLIONS of people in the database, there are bound to be things like suicides just out of coincidence.

Quote from: MrBogosity on August 26, 2015, 12:32:58 PM
It's possible, but do we know that for a fact? Or is it just that they were in the database? Of the MILLIONS of people in the database, there are bound to be things like suicides just out of coincidence.

They didn't specify how they were linking them.

However, taking a mid-range suicide rate of about 15 per 100 000 per year (which is middle of the pack for developed countries), the expectation rate would be about 6 per week from a population of 30 000 000.  We can safely assume they aren't just attributing all suicides among those who's info was leaked to the leak.

Quote from: evensgrey on August 26, 2015, 10:40:10 PM
They didn't specify how they were linking them.

However, taking a mid-range suicide rate of about 15 per 100 000 per year (which is middle of the pack for developed countries), the expectation rate would be about 6 per week from a population of 30 000 000.  We can safely assume they aren't just attributing all suicides among those who's info was leaked to the leak.

They'd also have to know they were in the database.