The Market Ticker
Commentary on The Capital Markets- Category [Company Specific]

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)

Ok, I'm officially pissed off.

BlackBerry has supported S/MIME on BES-managed devices for a while.  At least in theory.

However, the signatures it generates are invalid as they do not meet RFC requirements for MIME-encoded email.

It turns out that Outlook doesn't care, and thus "eats" these just fine.  But Thunderbird raises hell and says the signature is invalid.

It took me a lot of digging around to figure out the cause, and it turns out to be utterly inexcusable.

Here's what's going on.

When you send a MIME-encoded email (e.g. one with images in it, etc) the multiple parts are broken up and sent.  Each "piece" has a separator that is defined by the software (it's simply an arbitrary string that isn't anywhere else) and then before the content the type and transfer encoding is described.

The problem that MIME solves is that email transport is not 8-bit transparent.  That is, it normally is only printable characters that are guaranteed transport.  But a digital signature comprises bytes of any value, not just printable characters.  MIME solves this (as it does for pictures and similar) by using what is called base64 encoding.

But, email transports are also not guaranteed to handle long lines!  Most of them will these days, but historically they might not handle anything more than 80 characters before a carriage return, and unbounded line size can be a problem even today.  As a result base64's MIME type specifies that a base64 line must not be more than 76 characters and that any more than that must be ignored.  This prevents a potentially-malicious jackass from trying to blow up your mail transfer agent by sending an arbitrary (millions of bytes!) "line"; yes, defensive programming should prevent that from doing damage, but......

Here's a piece of a valid signature generated by Thunderbird:

Content-Type: application/pkcs7-signature; name="smime.p7s"^M
Content-Transfer-Encoding: base64^M
Content-Disposition: attachment; filename="smime.p7s"^M
Content-Description: S/MIME Cryptographic Signature^M

Notice that all the lines are cut off with carriage returns; this is what Base64 does and allows.

Now here is a similar piece generated by a BB10 device:

Content-Type: application/x-pkcs7-signature; name="smime.p7s"^M
MIME-Version: 1.0^M
Content-Transfer-Encoding: base64^M
Content-Disposition: attachment; filename="smime.p7s"^M

The signature generated is one great big line; there are no carriage returns in it at all!

Oh by the way, the same horsecrap happens when you send a signed and encrypted message -- although the data type is different (enveloped-data) the same rule on line length applies.  For this reason once again some email clients will blow up, particularly for large encrypted emails where the "line length" could be megabytes in size and thus exceed internal transport level buffering.

This crap is flat-out invalid according to the Internet RFCs that define email transport and results in the signature failing to validate against a client that processes digital signatures properly and enforces the MIME standards.  

Outlook, as with many other Microsoft products, doesn't give a rat's ass and accepts it silently but it shouldn't -- it should instead throw up and complain that the signature block is malformed (because it is.)

Thunderbird (and probably many other clients) refuses.  I have filed a bug report with Mozilla because the complaint should not be that the signature is invalid but rather than the signature block is malformed.

BlackBerry, this sort of incompetence in 2015 is utterly inexcusable, particularly given your previous violation of the rules regarding line terminators in the SMTP protocol back in the early days of 10.x and the fact that his has been going on now, as far as I can tell, since the initial 10.x firmware releases several years ago.

Fix this now and roll it out to everyone as the way your code stands right now S/MIME interchange is guaranteed to break with standards-enforcing mail clients and transports (and that's a lot of them, by the way.)

Until this is fixed and deployed this screw-up forces me to formally and publicly recommend against all BlackBerry devices in any environment where encrypted and/or signed email is part of the requirement set.  That, sadly, is all of them where BlackBerry is currently targeting its sales.

View this entry with comments (registration required to post)

For once the WSJ got the headline correct on a story.....

There’s a reason we don’t wear the same clothes two days in a row, try to avoid the temptations of McDonald’s and Ben & Jerry’s, keep a regular hair appointment and make it to the gym as often as possible. It’s the same reason we’d consider buying an Apple Watch: We like to look our best.

After over a week of living with Apple’s latest gadget on my wrist, I realized the company isn’t just selling some wrist-worn computer, it’s selling good looks and coolness, with some bonus computer features. Too many features that are too hard to find, if you ask me.

In other words you buy one because you think it makes you look cool -- and wealthy.

Uh huh.

You do remember the original digital watches, right?  The LED ones?  They ones that were dark until you pushed a button to light them up, because their displays consumed enough power that leaving it on all the time was an entirely unreasonable proposition in terms of battery life?

That's back in the Apple watch after having been absent for something like four decades!

We all got rid of that (serious) annoyance about 15 minutes after LCD-faced watches made their appearance; the essential function of a timepiece is to be able to see the time without doing anything other than looking at it.  The LED watch violated that and we (sorta) put up with it, but not really much by choice and, I might add, many people refused to buy one for this very reason.

Now those of us who don't wear a timepiece at all use our phones and we put up with the "push the button thing" to get the time from it when we want it.  Apple's gambit is that you'll be ok with a 40 year throwback in this regard.


Here's the thing -- I have a LCD watch that I rarely use right now.  I also have a couple of much-thinner analog-dial watches that I literally never wear, one of which (if I could find it) would almost-certainly have a dead battery and thus be useless.  On the other hand I have my Garmin 910, which I use all the time for workout tracking because it does an exemplary job of that -- and the Apple product simply does not.

Here's something you need to understand about "fitness" watches -- if there's any sort of mass to them the band must fit tightly and yet not dig into your skin.  That is the watch must not move on your arm or it will chafe as you run and you will find that if you run a good distance it will actually draw blood!

Garmin figured this out years ago and does it right; their bands have the right amount of "stretchiness" to both be comfortable and be able to be easily-adjusted so that the watch does not move while you pump your arms while running.  This is essential and most other "timepiece" style watches, along with anything that has a metal band, fails hard.

So what we have here is an overpriced "fashion statement" that has crap for battery life, is relatively bulky and doesn't have its own internal intelligence to do much (it relies on your phone.)  The one thing it appears to do well is serve as a workout timer and (provided you don't mind small storage) a means of music playback to bluetooth headphones.  That is a nice capability, but is it worth $350 for one piece of functionality that I currently don't have and might enjoy?

I think not.

As for the "style points" I don't buy into that at all, and in particular the notifications on the wrist thing is something I can do without.  Why?  Because I already have customized notifications on my BlackBerry Passport, so from the tone (and/or vibration pattern) I get with an incoming text or similar I already know if it's someone I am willing to interrupt an important activity for without having to look at anything.

Never mind that one of the advantages of having that vibration notification on the phone in your pocket is that nobody gets to see whatever it is unless and until you decide it's ok to look.  This is decidedly not true once you put the notifications on your wrist, and I'm not sure I like that at all.  "I'm waiting for you to get home in my birthday suit" isn't exactly a text I'd find amusing to have appear on my wrist where everyone can see it while in the middle of a high-powered business meeting!

I don't think this device will improve one iota on what I use an actual fitness tracking device for today, and probably will be worse -- particularly in the fit department.  And since it only works with iPhones, if you're not already an Apple Fanboi you get to buy two devices, not one -- making this not a $350 deal to try but rather a $1,000+ one.

No thanks.

View this entry with comments (registration required to post)

If you've followed me for a while you know I like this company.

The recent announcement of BES12 as a cloud service is a game-changer.  It used to be that you had to run your own server, and figure out everything related to it, to have BES in your enterprise.  This is still the right choice for the larger firm, but for the small company it may not be.

Mobile Management has all been centered around the medium-large to large company that has its own IT department and runs its own show.  The problem is that most businesses in this country are small-to-medium in size.  For the one man band none of this really matters, since you are the boss and the user.  But for the company that is still small but has employees, and has "things" they want those employees to have access to from mobile devices (such as an internal web site with price lists, customer data and similar) they are currently pretty much "out in the cold" when it comes to an easily-managed way to handle that and yet have a rational degree of security over that mobile access by their staff.

Now we have an inexpensive all-platform (IOS, Android and BlackBerry10) management solution available for about $3 or $6 a month, depending on whether you need advanced containerization on IOS and Android (it comes with all BB10 devices in the form of Balance) and other higher-level services for regulated firms.

It's called BES12 and BlackBerry is now selling it as a service instead of simply as a software product.  This means that you set it up on their infrastructure, they operate it for you but you administer and use it.  That, in turn, makes enterprise-class mobile device management and security available to the small business that lacks its own internal IT department in an extremely cost-effective fashion.

Now let's talk about how well this works, because I just went through it for my Passport.

It took me less than 10 minutes through a handful of web forms to order up the free 30 day trial and get it established; I set up a corporate account, signed in and set up the cloud "tenant."  Their system in turn emailed me a temporary password and login for the management system.

I was emailed a password and then told the system to send me an activation email, which it did, along with instructions on how to use it.  After putting in the required data on my Passport it set up the Balance workspace.

And.... that was that.

Next, I grabbed my Android tablet and activated it as well.  Downloading the BES12 client from the Play Store was painless and activation worked immediately.

How well does this work?

From my brief experience, flawlessly.

BES12 immediately detected that my tablet was rooted (it is) but I have that listed as permitted (by default it is, but it still gets flagged on the top level screen.)  For a real production network I would recommend "not", of course. The policy options all appear to work as expected.

So what do I think of this as an option for small and medium sized businesses?

I like it a lot as it's both inexpensive and painless.

Do I have complaints?  Yes, one serious one.  BB10 devices expect all work email and calendar connections to be on Exchange ActiveSync or IBM Notes Traveller.  This is flat-out stupid as many small and medium businesses (in fact, most of them!) run on some sort of other shared infrastructure such as Gmail (dumb though it may be to allow Google access to that data!)

Not allowing IMAP to be a work-related email connection for BB10 devices, and therefore excluding it from S/MIME and PGP, is utterly idiotic.  Gmail and most other "hosted" email services allow IMAP, which is a standards-based means of email exchange, and CalDAV and CardDAV are standards-based means of providing contact and calendar service.  BB10 devices know how to support all of these and it works flawlessly -- not permitting these options for the "work" partition is an absolutely unforgivable sin that Chen needs to fix right now.

Let's be clear -- this is 2015 and beyond the fact that end-to-end email encryption prevents snooping there is a more-serious matter when it comes to both internal and external communications: Digital signatures provide very solid evidence that a given message was not tampered with.  This is extremely important in a business environment where people are sending around proposals, contracts and similar.  For BlackBerry to cripple BB10 devices in this fashion, prohibiting anyone not on an Exchange server from using digital signatures, is outrageously stupid.

But that is not an indictment of BES12 per-se; it's a BB10 problem that has long existed (since the introduction of BB10!) when it comes to secure email exchange.  S/MIME has never worked outside of BES, but for BES it has never worked outside of Exchange servers and there is utterly no reason for this restriction as the software on the phone knows how manage the certificates required (and BES12 can push them, including private certificate authorities if you use them, making setup utterly painless from a user perspective.)  And for those who want to know this is not fixed in the next (10.3.2) software release either.


But other than this one complaint I have to say this much for BES12 -- It is a game-changer as it requires no IT department nor deployment of your own infrastructure, it's inexpensive and it brings real security policy and monitoring to the world of small and medium-sized businesses across devices including IOS, Android, Windows Phone and BlackBerry 10.

I predict success -- and market share -- for BES12.

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.