Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:Who are you defending against? (Score 2) 170

by blueg3 (#48614377) Attached to: Verizon "End-to-End" Encrypted Calling Includes Law Enforcement Backdoor

1. That's pretty common simply because getting anything approved for encryption above the SBU level is difficult and expensive. (It also requires, in essence, review by and the approval of NSA.) So tons of encryption products are made only up to the SBU level.

2. Even with end-to-end encryption, it's unlikely that they would approve classified data transiting the Internet.

Comment: Re:It's required (Score 3, Informative) 170

by blueg3 (#48614353) Attached to: Verizon "End-to-End" Encrypted Calling Includes Law Enforcement Backdoor

And the ARPA guys didn't consider that, because that first 'A' stands for "Army"

The "A" stands for "Advanced". I think they were more interested in a research network than a tactical (battlefield) network. I think it's still true that "one organization controls all the infrastructure between two points on the Internet" was *not* the model of the Internet they were envisioning at the time.

Comment: Re:This should be free (Score 4, Informative) 170

by blueg3 (#48614333) Attached to: Verizon "End-to-End" Encrypted Calling Includes Law Enforcement Backdoor

The issuer generally doesn't have a copy of your private key. You make a public-private keypair, put the public key into a certificate request, send the request to a CA, and the CA generates a signed certificate from it that includes the public key. The private key is not seen by the CA at any point.

You of course *could* have the CA generate both parts and then send you both the public and private key, but that's not nearly as good a solution and is much less common. Most of the CAs I've seen that provide "easy to use" interfaces generate the keypair in the Web browser so that the private key doesn't have to be transmitted.

Comment: Re:The website states exactly what yeast (Score 1) 50

by blueg3 (#48499797) Attached to: Open Source Craft Brewery Shares More Than Recipes

That's only true if you propagate yeast (internally) for many generations. You can also buy yeast, which a lot of brewers do because it saves them the trouble of doing careful quality control on a microbial culture.

It's also possible to acquire other brewers' yeasts unless they filter or sterilize their beer. Yeast labs do this on a regular basis and then sell it to other breweries (and to homebrewers). The yeast from The Alchemist, for example, is available from a couple of different companies now.

Only a handful of yeast strains are so interesting that their being "proprietary" is economically valuable. A lot of those have been cloned and are commercially available. Some are mixed microbial cultures (like with lambics), which are very challenging to copy because they're sensitive to their particular environment.

Really, the answer is that brewers don't worry about others stealing their secrets too much, because the market is big, it's pretty easy to make interesting beer recipes, and there are so many process variables that's it's very hard to make exact clones even if you have another person's secrets.

Comment: Re:You are a bit over a decade out of date (Score 1) 131

by blueg3 (#48471775) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

With respect, you are the one that came in with the childish "my platform is better than yours because your root can do anything" bullshit, so if you can't take a rebuttal then don't try to start such an argument.

No. You're completely imaging--synthesizing--that Windows is "my platform" because Secure Boot was mentioned. The whole argument of signing kernels, root compromising the kernel with modifying the disk, etc. is just as true in Windows as in Linux. You just change the jargon. It's absolutely the same system.

Incidentally, by the nature of my work, I have all kinds of different operating systems. Most serious work gets done on Linux, or, occasionally, OS X, because I can't stand MinGW / Cygwin and command-line is faster. I also don't have a Windows system that actually supports UEFI Secure Boot.

Comment: Re:You write of reading comprehension, yet ... (Score 1) 131

by blueg3 (#48466827) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

Just because you reject a simple solution in favour of complex one

Your simple solution is simple but unusable.
Signing binaries is not complex.
The UEFI Secure Boot implementation used by Microsoft is not the only way to implement Secure Boot.

Comment: Re:You are a bit over a decade out of date (Score 1) 131

by blueg3 (#48466807) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

So, most of that post was illegible anti-MS "I imagine everyone who disagrees with me is a fanboy" twisted worldview shit and is largely unreadable. I don't particularly agree with MS's Secure Boot approach, and you manage to point out why in the one coherent sentence at the beginning:

As distinct from the complex web of trust described above where all it takes is yet another leaked key to break into it and render all that TPM stuff irrelevant

Preshipping kernel-signing keys in TPMs and making it tricky to modify the trusted-signing-key list is a dangerous approach they've taken, for this reason. The benefit is that they can get people to actually use it. You can't get many people to use any feature that requires actual configuration. But key revocation is nearly impossible to get right in userland, so there's no way it'll work in a TPM -- a compromised signing key has carte blanche.

Incidentally, as far as I know, the TPM Secure Boot implementation doesn't use web-of-trust, it uses a typical PKI hierarchy.

Somebody clicking on a link in an Outlook message is all it takes to open up Internet Explorer to run whatever it finds in an "asp" script on a hacked MS webserver and next thing you've got files on network shares encrypted and some criminal demanding money - all before the MS or any other antivirus gets a chance to block it.

Secure Boot doesn't do anything to address user-space exploitation. It's not supposed to. That's a more serious problem for most users, yes, but different solutions are for different problems.

Incidentally, with a non-compromised kernel, an antivirus can, if it wants to, block anything before it executes. They hook system calls. They strictly get to operate before any change to the system occurs. In practice, this is often not done (which is why they're not very good), because characterizing "evil behavior" is hard, hooking all system calls is expensive, and people uninstall things that slow down their machine.

You can even, if you want, enforce that every executable memory page on your entire system have a SHA-2 hash that matches the hash for a page from the corresponding signed binary, so that you have no tampered executable memory pages on your whole system. The kernel will gladly do that if you implement it. You can even whitelist individual binaries (by hash+signature, no less), so that untrusted-but-signed binaries can't run either. It's been implemented on a Linux system, years ago. This approach does ruin Javascript, since it's JIT-compiled, but that's probably for the best.

Comment: Re:You write of reading comprehension, yet ... (Score 1) 131

by blueg3 (#48466709) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

I'm not cheering MS. UEFI Secure Boot is just MS strongarming people into actually adopting something that's been widely researched for a while now. People have had research-grade implementations of secure-boot for Linux for some time now. Hell, it was probably five years ago that there was a proof-of-concept implementation of a signed full stack on Linux that did remote attestation (so that a server could prove to a user that its software stack was untampered).

Otherwise, you're being deliberately obtuse in order to argue on the Internet.

The "reading comprehension" comment was in response to this:

what? you have given us no useful information. you talk of root escalation but don't even discuss how it could be done.

I said exactly what had to be done. It's simple. It does take writing to disk. I assume the anon is you, by the way, turning on the anonymous box in order to be a dick. Good job.

Read-only media plus turning off module loading is a solution to preventing adversaries from modifying the kernel, yes (provided you turn off some other kernel features also, and that your kernel has no exploitable bugs). Just "no module loading" is not a replacement for secure boot. It's a different thing. Read-only media is arguably a replacement for secure boot. You'll notice that not many people actually use booting from read-only media, and the reason for that is that it's terribly inconvenient. (It's particularly inconvenient to securely update the kernel without throwing away the read-only security benefit.) Signed kernels is a lot like that, except hey, you get to store your kernel on a normal disk, like most Linux distros expect you to do.

Comment: Re: You are a bit over a decade out of date (Score 1) 131

by blueg3 (#48461415) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

Christ, use a little reading comprehension.

Consider that in Linux, root is able to modify the kernel binary. So privilege escalation from root to kernel requires only a reboot and writes to disk.

1. Be root.
2. Use disk writes to modify the kernel binary.
3. Reboot

There are fancy ways to accomplish (2), but a suitable proof-of-concept is to completely overwrite the existing kernel binary (on disk) with a new one compiled by the attacker. That should make it obvious that the attacker gets to completely control what is in the kernel.

Line Printer paper is strongest at the perforations.

Working...