The Market Ticker
Commentary on The Capital Markets- Category [Company Specific]
2015-04-27 16:44 by Karl Denninger
in Company Specific , 138 references

So we all know by now that if you drop your iSuck (phone or tablet) from a height of a foot or two onto anything solid, due to the way it's designed (e.g. "glass first" at all corners and proud of the case) the odds are high that it will shatter.

Guess what -- the iWatch has the same design issue and does the same thing.

Now compare against Garmin's new "smartwatch", the Fenix 3 and soon-to-be-released Epix.  Notice that the mineral-glass crystals on those devices are slightly recessed, which helps protect them against the point-loading that causes tempered glass to shatter.

Oh, and if you want a sapphire crystal on the Fenix you can have it for the quite-reasonable price of $100 -- not that you probably need it given that Garmin paid attention to such things while for Apple, if it breaks when you drop it they appear to consider that a feature (for them, of course!)

View this entry with comments (registration required to post)

Fortune has an interesting article out on Facebook today that bears reading:

Even as Facebook tries to convince news publishers like the New York Times to publish directly on its platform—instead of just posting excerpts with links to their websites—the company continues to demonstrate why that is such a Faustian bargain. On Tuesday, for example, the social-networking behemothannounced some new tweaks to its news-feed algorithm, and warned that publishers might see a decline in “post reach and referral traffic” as a result.

Facebook wants publishers to actually post articles on the service instead of the more-common excerpt-and-link.  The reason for this is to capture the entire revenue stream from advertising on that particular story.

This, of course, is diametrically opposed to the interest of the publisher, who is not being paid by Facebook to post the material!  I'd be happy to post my articles on Facebook if and only if they paid me more than I earned from advertising on my own site.

Absent that why would you take Facebook's deal?  Nobody in their right mind would, if they understood it this way which is why Facebook, of course, doesn't explain it this way.  

They instead couch their changes in the form of "optimization" for the userbase.

Uh huh.

This will, in my opinion, eventually destroy all of the monetary value in the platform as what will ultimately be left are pictures of your neighbor's cat.

View this entry with comments (registration required to post)

Things that make me roll on the floor with laughter....

At San Francisco's RSA conference, an even more terrifying exploit has been revealed that has the power to send your iPhone or iPad into a perpetual restart loop. Mobile security firm Skycure has discovered that iOS 8 has an innate vulnerability to SSL certificates that, when combined with another WiFi exploit, gives malicious types the ability to create "no iOS zones" that can render your smartphones and tablets unusable. Before you read on, grab a roll of tinfoil and start making a new case for your iPhone.

An "exploit"?  Well, no, not really an exploit....

Basically what happens here is that the iPhone "trusts" certain WiFi networks innately (like attwifi named ones), which is rather stupid on its face.  Then you just have to feed a bogus SSL certificate to it, which the phone will solicit on its own when it sees that "trusted" Wifi SSID and bingo -- crash city.

It's one thing to crash an app but it's another when the operating system goes out and solicits this sort of connection on its own.  The latter leads to the ability to create a "No IOS devices zone" where anyone who wanders within range has their IOS devices all reboot continually on their own!

Clever, that.  Stupid Apple, that -- not just the flaw with certificate processing, but the "default" trusting of an open WiFi network in the first place.

'Ya gotta be fruity to carry that crap around in your pocket...... smiley

View this entry with comments (registration required to post)

The hits just keep coming.....

I finally drilled into the problem with S/MIME emails from BB10 devices (on BES or not) being improperly formatted yesterday and posted my findings here.

There's a related problem though that's at least as serious, and maybe more-so having to do with reading S/MIME emails.

Let's explain how this is supposed to work (and does, for all rationally implemented email clients.)

Public-key infrastructure is cool stuff but it has a general problem in that distribution of the public key is necessary through some mechanism.  S/MIME solves this in that whenever you sign an email your public key is sent with the signature, along with a list of the ciphers your mail system can decode in the order of the sender's preference.

Now this would sound like it's subject to tampering because there's no independent source of the key, but that's false because the key itself has to be signed by a certificate authority (CA) you have chosen to trust.  In other words if I tamper with your public key signature verification against the CA that I am trusting fails.

To sign an email I do so with my private key; you have my public key since the signature includes it and you know it wasn't tampered with because it validates against a CA you trust.  With that public key you can send me an encrypted message that only I can read (once encrypted not even you can read it!)

The same holds true in reverse.

However, BB10's email client appears not to validate and verify S/MIME signatures on its own!

This makes utterly no sense at all but it facially appears to be what's going on.

In other words BB10 appears to be using the BES infrastructure for signature verification but there is no reason for it to do that.

The process should be (and is on desktop and other mobile environments):

1. Read the message; if it has a Content Type of "multipart/signed" and a MIME component of "application/pkcs7-signature" with a name of "smime.p7s" (for "signature") it is a signed email and the public key of the signer is in that component.

2. Read the signature and the component(s) within the signed boundary.

3. Verify that the certificate in the signature is valid by checking it against the CRL (if included in the certificate) and the CA that issued it (which you have in the device's certificate store.)

4. Verify the message against the signature.

5. Display the results of whether (1) the message verifies against the signature and (2) whether the certificate verifies against a trusted CA.

Note that you might get a message that verifies but does not have a certificate you can verify.  This is ok; many organizations use "private" CAs, and it's perfectly acceptable to do so.  If you receive such a message you can ask the sender for his CA public certificate and load it into your device's CA store as a "trusted" source if you wish so you can verify future message certificates; for an ad-hoc one-off message this is probably not necessary but if you require no-tamper verification it is -- and is easily done.

For an encrypted message the process is the same except that you have the private key (yours) on the device necessary to decrypt it.  Again, if the message is also signed (and it usually is) you go through the previous steps as well.

What if you want to send an encrypted email to someone?  You must have first received a signed email from them, or have their public key via some other method.

BlackBerry, for its part, appears to not do the above on the phone itself without "help."

But there is no reason for any outside access to anything (Exchange, LDAP or otherwise) to be required except if you are trying to send an encrypted message to someone who you have no previous email from.

In that case alone a directory lookup for the public key of the recipient is required but in most cases you have it since the other person need to have only sent you a signed message you have not yet deleted for it to be present on the device.  The device need only look at those on-device messages to see if there is a signed email present from the target email address that the public key can be extracted from and, if there are multiple different ones found, it needs to ask which is the correct, valid one (or just use the most-recent, which is almost-always correct.)

The worst part of what BlackBerry does now is that if it receives a S/MIME message and the device is not on BES the signature is silently swallowed and ignored with no indication that it was present other than the "attachment present" indicator on the hub screen.  It is not validated nor is it left untampered with so you could (conceivably) analyze it separately; instead it is silently swallowed which is the worst of all possible sins to commit in that instance as the recipient doesn't even have a way to know that the sender signed his transmission!

BlackBerry, this is 2015 and S/MIME was designed the way it is for the explicit reason that key management is a pain in the ass and made PGP email unworkable in the wider corporate environment since there was no provision, in the general sense, to include the public key side nor any means of trust verification built into the system.

It's not hard to do this right but BlackBerry is still, in 2015 with an allegedly modern operating system based on QNX, doing it wrong.

I, and many others, want secure on-device email that works correctly in the mobile environment.  This is especially important in the era where corporate data is passed around or, for that matter, simple contracts where an irrefutable agreement to some clause that can be submitted to a court or other adjudicating authority in the event of a dispute is important.  That's virtually every company on the damn planet, large or small, and it not hard to do this right.

Someone will get this right and the firm that does has every right to claim ownership of the corporate mobile device space for email communications.

I'm tired of carting around my laptop for the purpose of reading encrypted email or simply indicating assent to a proposal with a legally-defensible digital signature -- and I'm not alone!

View this entry with comments (registration required to post)

It's about damn time.

BlackBerry has had leaked a feature in the upcoming 10.3.2 firmware release for all of their BB10 devices that should make the phones worthless if stolen.

When you do a "Security Wipe", or if you nuke the phone using an autoloader when it connects back to the network it will demand the previous BlackBerry ID, and force you to sign back in using the (current) password for it, before it can be set up.

Since this comes from BlackBerry's servers and is tied to the device PIN it cannot be overridden irrespective of what you do on the device, including destructively loading it. If you don't comply it will work as a telephone but all of the market, BBM and similar functions will not work.

This approach is far superior to an on-device protective function that allegedly "survives" a phone wipe because virtually all can be field-flashed with new firmware, and if the protection is on the device itself then it can be overwritten.  Since this implementation is linked to the device PIN which cannot be changed in the field it's going to be nearly impossible to circumvent.

The long and short of this is that if you steal a BlackBerry 10 device, once 10.3.2 rolls out, you have a worthless device from the standpoint of a "smartphone"; you instead have a device that at best is a "dumb" flip-phone in capability.

In a relatively short period of time this should utterly decimate the phone thieves game where they rip off a device and then resell it on eBAY or Craigslist, destroying the value of stolen devices.

Bravo BlackBerry.

View this entry with comments (registration required to post)

Main Navigation
MUST-READ Selection:
Wake Up America

Full-Text Search & Archives
Archive Access
Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.


The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be reproduced or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media or for commercial use.

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.