The Market Ticker
Commentary on The Capital Markets- Category [Technology]

And it is why, if there is such a thing as a firm that recognizes that security is important, my phone will eventually ring or my email will eventually have someone serious pop up in it.

Cybersecurity researchers at the University of Michigan were able to hack into Samsung's SmartThings, a top-selling Internet of Things platform. In doing so, they were able to acquire the PIN code to a home's front door.

The University of Michigan team’s “lock-pick malware app" was one of four attacks conducted as part of an experiment. The work is believed to be the first platform-wide study of a real-world connected home system.

Oh, and if you think that such problems are immediately fixed...

The University of Michigan researchers revealed their findings to SmartThings in December 2015 and the company is working on fixes. The researchers re-checked a few weeks ago to see if a lock's PIN code could still be snooped and reprogrammed by a potential hacker, and it still could.

That would be a "no."

BTW, SmartThings is basically a Zwave hub (although it does other things too.) 

My software, HomeDaemon, has been pretty-much under continual attempted assault since I first put it online.  Of course being online is kinda necessary for me, since I'd like to be able to see the house from "elsewhere".  I am, of course, more than happy to outline exactly why and how HomeDaemon has been designed to be highly-resistant to such attempted hacks.

The best part is that this wee little $35 piece of hardware does a fine job of not only defending against such shenanigans but also continuing to operate normally while under said assault..... 

View this entry with comments (registration required to post)
 

Gee, who warned you about this roughly six months ago.... and who has warned you over the years too?

The company behind Runkeeper, the popular fitness tracking application, is under fire overseas due to some questionable business practices. According to a complaint by the Norwegian Consumer Council, Runkeeper has been transmitting user data to servers — a major US advertiser, no less — even after the app and device have been idle for 48 hours, something that’s a clear violation of European data protection laws.

Runkeeper is not the only app that does this sort of crap.

I've caught a large number of other apps doing this, including, Charity Miles (also for runners) and some shopping apps such as WalMart's!  Interestingly enough some apps are also intelligent enough to not do it only if on Marshmallow where it's easily prevented (by turning off location) yet if they're on an earlier version of Android (Lollipop and before) they will do it, thinkin you can't track it or do anything about it.

Isn't that nice?

Oh, and why isn't that crap illegal in the United States?

View this entry with comments (registration required to post)
 

I am pleased to announce that the Freeware version of HomeDaemon-MCP is now available for public download.

What is HomeDaemon?  It's a piece of software that runs on a commodity (and very inexpensive) computer, the Raspberry Pi2 under FreeBSD.  It is capable of secure web service, master/slave setups communicating using and secured by bilateral certificates (e.g. your pool is run by a second unit that communicates in real time with the primary, a third runs your sprinklers, etc over either WiFi or wired Ethernet), direct digital output and analog inputs along with both Zwave and X10 protocols for easy home automation.  The CM11 (with all its warts) and CM15 (much-preferred) for X10 and the Aeon Z-wave Gen-5 stick for Zwave are supported.  AES-encrypted inclusion and operation on Zwave (for devices that can handle it) works, the software is fully event-driven and unlike all the other existing products that want to force you into a "cloud" paradigm that the company publishing it owns it is self-contained yet accessible via SSL from anywhere over any web-capable device, such as your smartphone, tablet or computer complete with multiple security levels so you (and not someone else) control what can be seen and changed by any given person.

The freeware version does not support encryption (of any sort, including on the web interface), master/slave (since that requires encryption and certificate verification) or physical I/O, but is otherwise fully functional.  It is my hope that an outfit that does home automation, or some entrepreneurial outfit interested in same, will want to pick this up lock, stock and barrel.

This (the full version, of course) is what I use to run my own home, it's entirely written by myself in "C", is extremely fast and secure.

You don't need to allow unknown corporate interests into your house to have "available from anywhere" monitoring and control of your home and in fact you shouldn't.  HomeDaemon-MCP not only shows that it's possible, but that it can be done in a secure and efficient manner.

Enjoy.

View this entry with comments (registration required to post)
 

Companies come into your private property and destroy what you own.

Seriously, that really happens today, and there's nothing you'll do about it.  You signed away your right to sue, and what's worse you still buy products and services from firm that do this sort of thing.

Apple Music is a new "subscription" music service.  But it has a twist -- when you sign up it will root around your hard drive (and, presumably, any network-attached drives) and any music it "thinks" it has in the "cloud" that it deems to be the "same" was what you own it will remove from your computer entirely.

This does two things to you immediately: First, it causes you to consume bandwidth (on the Internet, which depending on where you are and the circumstances may be metered, causing you to spend more money to listen to what you have already paid a fee to own.  But much worse is that it literally destroys your personal, private property.

Note that the files it removes aren't the same and can't be in essentially every case, because MP3s (or other compressed music) aren't the same as WAV or FLAC files and MP3s, even two rips from the same source, are often not bit-identical -- especially if the MP3 encoder used wasn't the same (there are several of them, you see, and they're all slightly different and some can be adjusted to produce different quality results, etc.) Further, WAV and FLAC files are frequently not bit-identical either, because errors happen and they're usually inaudible to you, but they result in slightly different files.  So "comparing" the files, when it comes to music, is always an inexact science.

No, what happens here is that Apple decides that it has the "same song", which means it removes files it doesn't actually have stored -- either not at all, of different quality, or a different version of a given tune -- and this can (and apparently does) extend to in some cases original music that you recorded -- that's right, music you authored and own all rights to.

The real "hook", of course, to this is to attempt to prevent you from leaving Apple Music.  By removing your music -- music you own, presumably have paid for and have stored on your own machine they try to keep you from canceling your subscription.  The hope, of course, is that you don't have a backup somewhere, or that you won't notice that the files are gone until you've overwritten said backup.

Then you're stuck as those files may be truly unrecoverable, in the case of something you bought via digital download.  If it was a CD you can probably rip it again.  Maybe.  You see, CDs are subject to bitrot, and I've had it happen a couple of times where music I own has become unplayable 10 or 20 years hence off the original CD.  Fortunately, my FLAC copy is securely stored and intact.

Why isn't this sort of thing a felony?  Why is it that a company can come into your home, onto your private property and destroy things?  Does a fine-print "license agreement" cover this sort of situation when there's no possible way you gave actual informed consent?

It most-certainly should not, but today it sure appears that it does.

More to the point is that you, the American Consssssuuuuuuummmerrrrr, have made this sort of crap possible.

You have made it possible because you will buy products and services from companies that pull this sort of crap.

We as a body politic deserve this sort of outrage because we permit it.  We permit it by allowing firms that build walled gardens filled with various means of enslavement to their cash flow to exist by voluntarily paying them money for goods and services.

We're stupid, to put not too fine a point on it, and until we cut that out and start being smart this sort of ass-reaming is not only what we're going to continue to get, it's what we deserve.

I have never owned a piece of fruit technology and never will.

This sort of outrageous practice, which I remind you began in the music realm for Apple with their iPods and "secured" music that was not transportable to anything else even though you bought it, is why.

I'll start feeling sorry for the author of that blog when he, and the rest of you, financially destroy companies that have a decade-plus long record of doing this sort of thing by refusing to buy their products and services.  When their stock price is zero and there's a big smoking hole where their balance sheet used to be through entirely lawful and voluntary response to such tactics then I will feel sorry for you.

Until then I have just four words for you: You asked for it.

View this entry with comments (registration required to post)
 

I've been under an NDA and thus couldn't post this for a while, but with the now-released Marshmallow update for the Priv BlackBerry has elevated itself to being the only Android-based smartphone you can purchase if you have any concern for actual security.

Let me explain.

Security is always a balance between hassle and safety.

That is, you can always design an extremely secure paradigm for something, but as you do so the hassle factor tends to increase.  At a certain point people say "**** it" and start cheating.  This is why "password re-use rules" tend to get violated by the user putting a sticky note on their terminal, for example; if you say "must be 10+ character, must contain at least one number, one special character and both upper and lower case alpha, and must not be any of the last 10 passwords" you're inviting the user to write it down.

Of course once written down it's no password at all if anyone can see, photograph or steal said piece of paper!

The same applies to phones.

One reason people have their phones broken into is that they use easy PIN numbers.  A 4-digit PIN or a "pattern draw" is pretty easy.  It's also not very secure.  Neither is a "fingerprint" especially when yours are probably all over the device and can be lifted in 30 seconds using a piece of scotch tape!  After all you only care about your device being broken into and its data pilfered after it's been lost or stolen at which point wiping it off is going to be kind of hard!

long alphanumeric password is extremely secure.  It is also a pain in the ass to key in every time you want to unlock the phone.

BlackBerry has, for quite a while on BB10 devices, had a nice mixture -- Picture Password plus the ability to use a long alpha password.  The picture password is much more-secure than a PIN or a pattern, but also very convenient and quick.  It's the only means that I've seen that is both very secure and resistant to even direct observation.  I've challenged people at my local watering holes repeatedly to watch me unlock my phone using it, then handed it to them and asked them to unlock it, offering a beer should they succeed.

I've yet to have to buy anyone a beer.

But the Priv, on initial release, had a problem.  Android 5.1 couldn't use the Picture Password to unlock the trust store.  That is, the Priv has hardware-backed trust storage for credentials -- including VPN certificates and similar which can contain a private key and thus must be protected.  If those are stolen the certificate is irrevocably compromised and would have to be revoked and reissued, assuming you know it was stolen.

Thus, if you had such things, or had passwords for other applications you cared about, you were forced to not use Picture Password and had to either use a PIN (sort of crappy security if more than 4 digits to terrible if only 4), a pattern (terrible security) or an alphanumeric password (excellent if long and complex but a severe pain in the ass.)

Marshmallow has fixed this.

You can now set up the phone the following way and it is the only way that is both convenient and secure.

  • A long, alphanumeric password required on boot.  No password, no unlocking of the FDE in storage, tough cookies you're not getting in.  Assuming there is no back door to the FDE a long password and strong key derived from it means "forget about it" when it comes to breaking into a turned-off device.  Period.

  • A picture password for the lock screen.  This now gives you both reasonable security and convenience.  Unlocking is extremely fast and convenient and rationally secure as the underlying unlock is the alpha password.

Five fails at the picture password sequentially forces you to input the alpha one.  If you don't know it, tough cookies.

What potentially remains active as a vulnerability is an Android Device Manager unlock via Google's services.  This can be disabled (you can revoke Device Manager's access if you wish), but there is a risk in doing so in that the Android Device Manager also allows for remote wipe.  It is unknown whether there's a back door in that code from Google but one must assume there is, so for maximum security you should shut it off and disable automatic updates to applications.  This should prohibit OTA updates without unlocking and your permission.

Since the Priv has a hardware-backed security storage module this now narrows the assault vector on the phone to being able to break the TCM.  That is a very narrow attack surface compared against everything else on the market in both the Android and IOS space.

Is it perfect?  Not having source access I can't say, and I don't trust Google (any more than I trust Apple!)  However, this renders the device quite-arguably the best current example out of any smartphone with a "popular" operating system when it comes to security structure periodand as such it's the only device I can recommend to those who care at all about the security of their data in a handheld device who also insist on having wide "app access", irrespective of who you care about protecting it from.

DTEK has also been updated since with permission management you not only now know which apps are accessing data you can shut off their access to same, and you should.  Location data, in particular, ought to be off for most apps although nearly all ask for it.  Why does WalMart's app need to know where you are, unless you're searching for a WalMart near you?  It doesn't, so turn it off to prevent it from sending your location to "mommy" every five minutes!  While base Marshmallow code now allows this from any vendor only BlackBerry's DTEK tells you what's being accessed and when so you can make an intelligent decision on what to shut off.

And finally the excellent BlackBerry "soft" keyboard now supports swype typing if you wish to use it.  It defaults off but is in the settings, can be turned on if you wish for the soft keyboard, the hardware keyboard or both as you wish, and works nicely -- without having to load the Swype keyboard and lose all the other BlackBerry keyboard goodness.

In addition Marshmallow took the Android 5.1x (and previous) niggles (which were not unique to the Priv; all were common to all Android phones) and got rid of many of them.  Among other things power management is materially improved (standby endurance has roughly doubled) and granular permissions are something Android should have had forever (and did back in 4.x if you knew how to find it, but Google removed it on purpose) so you can deny apps access to things like location -- and you should for essentially all, given how often they will steal that data and send it home to "mommy."  The age-old problem with Android interacting properly with Bluetooth AVRCP (e.g. volume controls on a bluetooth headset or paired car don't actually control the handset volume, they're separate) is fixed.

In addition while it is not yet fully fixed (and I hope that is corrected very soon!) S/MIME is now supported internally in the Hub.  This marks the Priv as the only Android handset with a well-designed and native integrated S/MIME client providing end-to-end email encryption for which there is no centrally-held key or back door that a manufacturer can turn over or "leak", court order or no.

Google will never do this, by the way, since Gmail rests on their server and they rely on being able to scan your email for advertising, an act that is impossible if the message body is encrypted!  And while other devices can load third-party software to do S/MIME or use non-integrated clients they may include the point of it being integrated is convenience, which is a huge issue -- security features you do not use because they're a pain in the ass are for all intents and purposes not there.

For those who care sending signed messages does not currently work properly.  Encrypted or signed and encrypted are both functional.  This is a problem mostly in the area of key exchange between correspondents, as the usual means of getting someone else's key to send them an encrypted message is for them to send you a plain-text signed one; the signature contains their certificate which you can then use to reply encrypted (and signed.)  There are ways around this (if your correspondent sends you a message first you can reply encrypted/signed, and he now has your certificate) but this does need to be addressed.  In addition for those with private CA infrastructure certificate verification is not working properly (the message will decrypt or validate as signed but the certificate itself does not verify); this is a serious issue for high-security enterprises and government agencies (think DOD, for example) who keep control of their entire certificate infrastructure as the entire point of certificate verification is knowing that the person who you're talking to really is who they say they are.

Neither of these problems should be hard to resolve and they can be fixed with a Hub application update (that is, without a full software release) but it's only fair to mention that they exist.

Bravo BlackBerry; you took a nice handset with a decent security posture (but a material pain in the ass to use in a secure fashion) and turned it into one with a materially better security posture that is no longer a pain in the ass.

While the user experience improvements are available on any Android device running Marshmallow this is not true of the security posture improvements, most of which center around making security convenient enough that you'll actually use it.  

Those are all BlackBerry-specific and cannot be found on anyone else's Android handset.

In other words there is now only one choice for security-conscious users in the Android marketplace.

BlackBerry Priv.

(Available from AT&T, T-Mobile, Verizon and unlocked, direct.  Note that at present only unlocked direct handsets have Marshmallow available; carrier versions are reported to be expected to receive the update starting around the first of May.)

View this entry with comments (registration required to post)
 

Main Navigation
MUST-READ Selection:
Dawn In 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.

NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.

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.