No; iMessage isn’t intercept-proof.

*** (April 5, 2013) Update: TechDirt has a nice post about the whole affair. They summarize the counterarguments against the DEA memo and the original CNET story; and they line up quite nicely with mine ūüôā They also include snippets from Julian Sanchez that offer more details and some possible motives for this whole exercise. Woot!

Argh. This story is traveling around the OMGosphere. A DEA office sent an internal notice among its agents and investigators. The notice was meant to warn them about the inability of pen registers and trap and trace devices to log Apple iMessages. The devices in question work like the call list on your phone; every call you make and every call you receive are logged. Extend that idea to include SMS messages (mobile texts) and you get the idea. It’s a form of wiretapping, but it doesn’t necessarily include logging the content of the communication.

The DEA uses these devices to record evidence of contact and communication between suspects. If they’re logging the phone calls made and received by gang members, the record of their intercommunication history could be used in court to show collusion in criminal activity, for example. RICO Act type of stuff.

Most of this equipment is installed and maintained by the phone companies to meet their legal disclosure requirements; when an agency comes knocking and asks for a full bidirectional record of calls for a certain phone number, the company is required to produce it.

The DEA warning was issued because agents discovered that the communication records they received weren’t always complete. The missing events were iMessages sent between two Apple devices; two iPhones, an iPhone and an iPad, two iToilets, etc.

So, that means that Apple iMessages have unbreakable encryption and are so amazingly great that EVEN THE DEA CAN’T TRACK THEM! ¬†Right?



Internet, there are times when I want to hit you with an atomic hockey stick.

DEA foiled again!

Why are SMS messages logged while iMessages are not? A few reasons that have nothing do with super Apple encryption framice plates.

1. SMS messages are handled by the phone company network. The capability to transport text messages between mobile phones is built right into the specifications of the mobile phone networks. When you send a mobile text message, the message protocol includes source and destination headers telling the tower where the message originated and who it’s for. The logging equipment at the phone company can simply take those headers and add them to the record.

2. iMessage is not a standard adopted by the Mobile Phone Industry. Apple handles the routing of iMessages. When you send an iMessage from your iPhone — assuming you send it via mobile data and not Wifi — the cell tower treats it like a bunch of ordinary data packets; you might as well be uploading a photo or streaming some music. The packets will have source and destination headers of their own, but only to move the packets to an Apple server. The actual source and destination of the iMessage will be part of the data packets’ content, not as cleartext metadata on the outside of an SMS message.

3. Pen registers and traps aren’t psychic. There are people in the world who think that a virus scanner is capable of identifying any kind of virus. Surprisingly, the scanner is not an oracle; it’s just pattern matching to a list of known patterns. Have you ever been bothered by anti-virus software begging you to update your virus definitions? The software needs to have the latest set of known virus patterns (or signatures) so that it can detect known threats. If the definitions haven’t been updated in 2 years, there are lots of new virussessesesesssii the scanner will miss. The wiretaps can work in a similar fashion. They can sit in the network and look for SMS-shaped things, voice call-shaped things, etc. They have been told how to identify those events; they don’t get a tingling spidey-sense when an SMS is nearby. It’s entirely possible that the wiretap equipment could be given an update allowing it to identify the signature of an iMessage, if not the ability to decode it. Depending on the iMessage spec, messages may have a structure that is observable even when encrypted; messages may have a specific preamble; all packets heading to a set of identified iMessage servers could be flagged, etc.

4. It is almost certain that Apple IS maintaining a log of iMessages in order to comply with legal requirements. If so ordered, they would be required by law to produce activity logs for individual iMessage accounts. In this case, the DEA agents weren’t aware that the Apple-held data wouldn’t be logged by the phone company. This wasn’t a triumph of Apple tech against evil government privacy violations. This was a temporary ignorance of modern communications tech.

Thus endeth the lesson.


[Analysis] Minuum and the Quest for a Better On-Screen Keyboard

Update: It looks like they reached their $10000 funding goal within a day. I guess it’s time for my dancing cookie-dispensing robot idea to greet the world…

Everyone’s aflutter about Minuum, the on-screen keyboard concept looking for funding on Indiegogo. ¬†The reactions fit into the usual classifications: this sucks, this is stupid, this is amazing, this is genius, this will change the world, this has no hope, try mine instead, you’re stupid, you’re stupid but I’m smart. ¬†Very informative.

Continuing my quest to over-analyze everything as though it were a fine wine (or decent winegum), I provide you with my initial analysis of their initial promo material, initially initialed intricately in triplicate.

The Analysis

A writer of type.

They hate typewriters.  Or, or, they badmouth typewriters but like to show them in their fundraising video.

I know, it’s just a marketing video, it’s a commercial, it doesn’t represent their intellects nor their capabilities. ¬†But it is annoying to hear the same half- or quarter-truth repeated by designers promoting their latest interface improvement. ¬†The fractional truth in question: the influence of typewriters on modern interface design.

It’s almost obligatory for someone to mention typewriters when presenting a new interface design – especially anything keyboard-ish. ¬†The argument goes something like this:

  • typewriters are over a century old
  • they had a big problem with keys getting stuck together
  • so they made the layout less-efficient and slowed everything down
  • modern devices aren’t anything like those old wing-dingers with their cogs and cranks
  • therefore it’s stupid or at least strange to make modern interface devices work in some way similar to those old contraptions
  • It may even be treason.

To which the proper response is “Yes, but…”

Yes: It’s true that the QWERTY layout isn’t optimal in terms of key location relative to letter frequency (the more common a letter is used in the English language, the closer it should be to a fingertip; the least commonly used letters should be farthest from the fingertip in that case, kinda sorta), and it’s true that modern keyboards and on-screen/virtual keyboards don’t have the mechanical issues that called for the use of QWERTY.

But: there are oodles of good reasons to use some typewriter-related concepts, there are many ways that on-screen keyboards are fundamentally inferior to typewriters, and it’s misleading to invoke the typewriter in comparison to your product without elaborating.

The QWERTY layout is really the only thing that an onscreen keyboard takes from the typewriter. The relative size and separation of the keys on the screen is to make targeted touches easier for the user – they can easily judge whether they’re between two keys, directly on one key, or somewhere else. ¬†Physical keyboards and typewriters give us all sorts of tactile feedback that we don’t get on a screen, so it’s hard to touch type. ¬†We just can’t feel precisely where our fingertip is on the virtual keyboard; there are no raised edges, no valleys between keys, no concave surface to invite a fingertip in for a rest. ¬†This loss of feedback has a much larger impact on interface efficiency than is generally recognized, and I’ll be addressing it in a future article.

So the user gets no tactile feedback cues to guide the finger placement. ¬†That’s a negative for any on-screen keyboard, but at least they all have it in common. ¬†What, then, separates the good screenboards from the okay, the okay from the bad?

As always: it depends. ¬†There are all sorts of objective and subjective ways to measure and compare screenboards, but which measures really matter? ¬†Minuum‘s premise is that the default style of screenboard is usually something large with typewriter-like layout and separation between the keys, something that often covers half of the screen in a way that is distracting or otherwise negatively affects users, so it would be of benefit to have something that is functionally equivalent to a big screenboard but much smaller and less obstructive. ¬†I agree that the large boards are obstructive and disrupt the flow of the experience, but I have some issues with their solution…

Even though the half-screen virtual keyboards eat up so much space, the user is able to trust that the keys will always be in the same locations on the screen, no matter what they do (except for switching to alt characters, number boards, etc.), and pressing a key always results in that position’s character being added to the input buffer. ¬†The Minuum type of predictive entry starts as a sort of compressed QWERTY board which lets you choose a “first candidate” character. ¬†A mini-board pops up above the first board and includes guesses about what character you were actually trying to hit; this can be characters to the immediate left and right, or the next letter of a word that it thinks you’re trying to spell. ¬†It’s not obvious from the video whether a second selection is necessary if the first guess was correct; it could just wait for a delay and then push the guess onto the input buffer.

The point here is that flat QWERTY is the only constant part of the board; the virtual keys are lined up shoulder to shoulder in one long, thin row and it would be difficult to choose the desired key on the first click. The mini pop-up board’s contents are not static – they can change depending on tiny differences in finger position on the first pass and depending on predictions about the word or string you’re trying to type. This means that the only constant part of the board is hard to use on its own, and that you’ll have to do a two-stage selection using a board that isn’t static.¬†

I’m not saying that this won’t work or anything like that. I’m just saying that the way this operates goes against some UX principles at first glance. If the prediction algorithm works well, you’ll be saved a lot of extra key presses, and that’s good; after typing the first 5 letters of “antidisestablishmentarianism”, it lets you click on the finished word and saves you all that isestablishmentarianism. ¬†If you’re typing a lot of non-dependent (non-predictable) text or strings, like alphanumeric passwords or LULZSPEAK TXTING LING0, you’ll have to more actively scan the mini-board for the correct character (since you won’t know what characters it will include) or use the “magnifier” feature (which is really a 2-stage board without the prediction feature).

In general, the more the user has to actively think about something, search through sets, make judgments, etc., the less optimal the interaction will be. If the board layout remains constant and the fingertips are moving to a fixed location each time for a specific key, the process becomes less and less a conscious task. Physical keyboards are great for this because the keys are always in the same absolute position and there are many little tactile and auditory clues and cues that feed back to the motor control, helping to make precise key presses without needing to visually track the finger’s position or do any conscious processing.

Now, I must stress that I don’t have any more information about Minuum than anyone else who has only seen the promo video, so I’m speculating about some of the details and about what manner of beast will be the final product ¬†Feel free to point out any glaring mistakes in my reasoning or understanding.

I wish them good luck in fundraising and good luck in the market.

Android Phone Goes Inky. E Inky, Prototypically Speaking.

Wow, what a great headline…

I read an article at Laptop Mag regarding a prototype Android phone that uses an E Ink display. ¬†My inner critic decided to outwardly criticize, producing a rather lengthy blog comment. ¬†I reprinted the comment here on my own blog because… well, why not?

Laptop Mag’s hands-on demo:

My response:

Notwithstanding the super-light weight and super-long battery life that E Ink affords this device, the display is a showstopper. The talk about using an older processor is a red herring; a faster processor won’t fix fundamental characteristics of the display. The currently available generations of E Ink give you a trade-off between refresh speed and power consumption; crappy refresh rates mean long battery life, fast refreshes are draining.

The E Ink screen is great for displays that don’t require rapid refresh, but this prototype demonstrates how inappropriate it is as a smartphone’s primary display.

Motofone F3

When you buy an Android phone with multi-touch, the implication is that you’ll be interacting using finger swipes and taps, and that your interactions produce feedback quickly enough to make the experience seem natural and effortless. What we think of as normal single- and multi-touch functions would lose much of their utility; pinch-to-zoom, for one, would be a noticeable series of zoom-in steps (instead of a fluid growing and shrinking effect), something you could achieve with a zoom-in button and a single finger.

I‚Äôm not trying to bad-mouth E Ink, here ‚Äď this is just not a viable application until/unless E Ink rolls out a display that gives you imperceptible refresh without massively increasing power consumption, hopefully at a reasonable price.

It would be cool to have the option of swapping your phone’s display, either physically changing it for another one or flipping one over the other like a book cover. There are times when I wish my display was e-paper, but then I look at my Motorola F3 and all is forgotten.


Google Play says your username and password don’t match?

UX designers and coders take note: nothing will frustrate your users more than being asked for login credentials and being told that they’re wrong.

This is especially true when the user (me) is trying to enter a long alphanumeric password on a tablet with a stylus. ¬†Every time the user sees “username and password don’t match”, they will naturally assume that they’ve hit an extra key or capitalized something accidentally, and will grumble to themselves as they try again. ¬†Things get even more fun when the password field is masked with stars to prevent shoulder surfing.

It’s pretty easy to humble your user this way. ¬†So easy, in fact, that you should spend time analyzing the user’s task to see if you’re asking them the right questions and giving them enough help…

Case in point: Google Play Store. ¬†I have a very low cost (cheap) tablet on which I managed to load the Google Play packages. ¬†When asked to login to my Google account, I received the very helpful response “username and password do not match”. ¬†I attempted to login several times with my normal credentials and failed every time. ¬†There were any number of reasons for this to have failed (including the fact that my tablet was unsupported, ahem), but the real reason was ridiculous:

I use Google’s two-factor authentication.

Logging in to Google from a new computer usually means entering my username, password, and then a 6-digit number that is sent to my cellphone over SMS. ¬†If I enter the user/pass incorrectly, the error would be “username and password do not match.” ¬†If I enter the 6-digit number incorrectly, the error would be something like “incorrect PIN.” ¬†This is straightforward proposition: enter your Google username, your Google password, the PIN that Google sends to you; if you get something wrong, you entered the user/pass incorrectly, or you mistyped the PIN.

Google Play’s device login, however, doesn’t mention anything about PINs or two-factor authentication. ¬†A naive user, like myself, assumes that he must enter his normal Google username and his normal Google password. ¬†But that’s¬†wrong. ¬†Normal username, yes, but you¬†must enter your “application specific password”.

What’s that? ¬†Rather than implementing the SMS PIN step, Google lets you create a sort of special password that you only use on mobile devices or desktop apps. ¬†There are many good reasons for doing this; it’s extra security against rogue apps or compromised devices (not exposing your main Google credentials), it saves developers using Google APIs from having to rework their products, and the application specific password is only made of lower-case letters so that mobile users won’t have to fiddle with entering special characters.

Good reasons, all of them. ¬†But it all falls apart at the user interface. ¬†Users are dependent on the UX designer to give them the information they need for the task. ¬†Failing to mention mention that “password” could mean “application-specific password” is a big omission. ¬†Google’s support site does mention the issue, and users of 2-factor authentication are told in advance to expect this behaviour, but that doesn’t cut mustard.

Now, back to my under-powered plastic tablet and its slight violations of terms of service…

Curse of the Samsung R330 Firmware Phantom

I spent far too much time trying to fix a cell phone, today. ¬†One of my kin has a Samsung SCH-R330 feature phone with Bell. ¬†A week ago, it began freezing and soft resetting whenever the “1” key was pressed at the beginning of a number. ¬†This meant that dialing long distance or using the hotkey to access voicemail would reset the phone.

The error would go like this:

  1. Open the phone and press the “1” key
  2. The screen goes completely black for about 2 seconds, then the image returns but the phone is unresponsive for 10-15 seconds.  Button presses do nothing, and no button tones are played through the speaker.
  3. The screen will display “Looking for service” or “Home only mode” or some other network-related message. ¬†Phone responds normally to button presses now.

The static image on the screen and the non-responsive buttons looks like a soft reset. ¬†The image would be sitting in the screen buffer and that buffer probably doesn’t get flushed or updated until later in the reset sequence.

There’s some key information here for the troubleshooting process. ¬†The screen buffer is probably just a designated spot in the phone’s RAM. ¬†RAM is volatile, meaning that any information is lost when power is off…

When the button was pressed, the screen went black, and we could presume that a black screen meant power loss. ¬†Superficially, the relationship looks like this: button press => power loss. ¬†A button is just a bit of conductive material that bridges a path in a circuit; you press it, the circuit is closed, current flows. ¬†Ideally it has only two states, On or Off. ¬†But what about a short in the circuit? ¬†If some conductive foreign material gets into the button gap or otherwise causes the button’s conductor to deflect onto another path, a short circuit could be created, bypassing all of the logic circuitry and putting the phone into an error state. ¬†Depending on the location of the short, the phone might power off completely, just like removing the battery while the phone is on, but, if the short only caused a logical fault and not a loss of power, the phone’s processor would just fall back to a reset mode and go through the boot process.

The phone cam back to life by itself, so that seems to rule out a total loss of power. ¬†And, if we recall that the image on the screen reappeared after going black, we have more evidence of a soft reset. ¬†If there had been a total power loss, the screen buffer would be empty, so instead of a nice main screen image, we’d see a blank screen or the default loading screen you see when the phone is first powered on.

So is it a short? ¬†If we presume that it is some mechanical problem with the button or some related structure, then the error should occur regardless of the state of the phone. ¬†That is to say, the error should happen regardless of what app is running, what menu is on the screen, what order I press the buttons, etc. ¬†Simple enough to test: press the “1” button from the main screen, from the main menu screen, in Camera mode, in Text Messaging mode, as the first number, as the middle number, as the last number, and any other way you choose.

What we find is that the error DOES depend on the state of the phone. ¬†If you dial “54321”, everything is fine. ¬†If you dial “12345”, the error happens when you hit the “1” button. ¬†The error happens at the main screen and in the main menu, but does NOT happen in Camera mode or in other sub-menus. ¬†A mechanical fault would not be dependent on the logical state of the phone. ¬†So it cannot be the button itself.

If an error depends on logical conditions, then perhaps the error is rooted in logic. ¬†To be more specific, the logic of the phone’s software. ¬†The phone itself is an electromechanical device, but it needs a set of instructions to tell it how to behave like a phone; communicating with the cellular network, displaying an image on the screen, responding to a button press, etc. ¬†The instructions are called firmware. ¬†Firmware is like software in that both are sets of instructions for operating a logical device, and both can be changed by reprogramming, but one thinks of firmware as being more intimately married to the device than regular software. ¬†Firmware usually lives closer to the device’s “brain” and contains everything that is necessary for the basic functions of the device. ¬†Software is a more general term and, in the context of this post, is something that would add other functionality to a device, like apps on an iPhone, but be an option rather than a standard part.

Barring a curse, demonic possession, or the ghost of LeVar Burton, the problem boils down to the firmware. ¬†As the phone follows its instructions and moves from state to state with button presses and cell signals, the phone is put into a state where a single press of the “1” button gives the processor a value it doesn’t expect or a command it cannot execute, and it panics. ¬†It’s a bug. ¬†Maybe the instructions say “if Button 1 is pressed, go to the instruction at location ABC” but ABC does not exist, or contains something other than a legal instruction. ¬†I don’t know.

“So, Mr. Gilliland. ¬†Should I toss the phone in the garbage?” you ask.

Well, yes. ¬†It’s an old feature phone. ¬†Crawl out of your bunker and join the 21st century.

If you’ve bothered to read this far into the article, you probably want to keep using the phone, so I have good news. ¬†The fix is simple. ¬†Turn on the phone and navigate to the main menu, the one where you see “Tools”, “Camera”, “Messaging”, etc. ¬†Usually you just have to hit the big round button in the center of your keypad to bring it up. ¬†From within the main menu, press the SOFT BUTTON on the TOP RIGHT of your keypad. ¬†It looks like a hyphen or a minus sign and it’s just to the right of the round center button (but it’s not part of the ring). ¬†This should bring up a box with two options: ¬†Menu Style #1, and Menu Style #2. ¬†Use the button ring to select Menu Style #1, then press the round center button. ¬†The main menu’s background colour should be black, now. ¬†If it is, you’re done.

Yes, that’s it.

The error only happens if you have changed your background to Menu Style #2: White.

White background + “1” button = crash.

This is a firmware issue, so technically it can be fixed by flashing a new firmware into your phone. ¬†The firmware is distributed by your carrier, Bell in my case, and the phone has a simple option in the Tools menu to install the latest firmware. ¬†According to the phone I’m working on, it already has the newest firmware, which means that either Samsung doesn’t want to produce a newer firmware, or Bell doesn’t want to bother with updates for an old feature phone. ¬†I asked Samsung Support via Facebook (who responded quite quickly to my initial pleas for help) if they offered a generic, non-carrier-branded firmware to end-users, but I haven’t heard back. ¬†There’s just about zero chance that they would offer such a thing, since the carrier prefers to own any relationship to the end user and decide what features and customizations should be enabled on the user’s device.

If you’ve experienced this weird bug, send me an email or leave a comment on this post. ¬†I looked high and low for a documented case of this bug and found nothing, so I hope this helps someone.


Streaming Music WILL NOT Destroy the Planet



A report with a very “link bait” title is making the rounds: “The Dark Side of the Tune: The Hidden Energy Cost of Digital Music Consumption.”

The premise is thus:

  • Music used to be encoded on physical objects, like records or CDs (things which had a one-time energy cost), that were possessed by a consumer
  • Music is transitioning from physical storage to electronic storage; the consumer doesn’t keep an object in his house, he just requests that an electronic copy of a song be sent to him via the Internet
  • It doesn’t cost much to transfer or “stream” music in this way, but it must be done many times over the life of the consumer
  • The net energy cost of streaming* music** will far outpace the net energy cost of providing music on physical media
  • Music** streaming* will some day consume a double-digit percentage of the world’s energy¬†production (unless we start a concerted effort to find new technologies, why oh why haven’t we started researching these things, oh wait we have, why are we writing this report in the first place)
* The report arbitrarily assumes that half of all music streaming will occur using wireless networks, presumably using much more energy per unit data than physical networks.

** An interesting bit of conflation happens here: the report is nominally about music, but the calculations of bandwidth usage include things like uncompressed video.

The first three points are basically true.  The latter two are bat-shit insane.

Some doozies I cherry-picked from the report:

¬†“Even with all traffic moving over to WiMAX, this traffic will nevertheless consume the energy equivalent of 21 per cent of the world’s total electricity consumption in 2010.”

!#%$&^%!&%!!!!!!! ¬† They’re suggesting that in 2027, 1 billion people would be using WiMAX (a questionable assumption) as their primary music-streaming connection (a very questionable assumption) with the same rate of power usage (an even more questionable assumption) per unit data transferred.

“To further illustrate the scale of data traffic and its energy drain, 2011 YouTube statistics indicate some 4 billion video streams per day [see Appendix 2]. ¬†Assuming a 1GB file size per video (half of YouTube’s 2GB cap), this represents daily data traffic consumption of approximately 8 exabytes – annually equivalent to 0.1 per cent of the world’s electricity consumption in 2010.”

!^$&@%$&!%@&$T!!!$R4!!!  I like that they arbitrarily set the average file size at half of maximum size.  I was once able to eat an entire cake for dinner, therefore I eat half a cake for dinner each night.  Lunacy.  There are a whole bunch of faulty assumptions being made.

  1. Even if a user has uploaded a 1GB video to YouTube, that does not mean that all the viewers will be downloading 1GB each time they view the video.  YouTube converts all videos to multiple sizes and qualities.
  2. There is no way in hell that the average video size is even close to 1GB.  According to this study done in 2010, the average length of a YouTube video was around 4 minutes.  Even if we are generous and assume that all videos are HD (around 20MB per minute), that works out to 80MB average.  80MB versus 1000MB.  A bit of a difference.
  3. The study assumes that 2 billion people globally will be streaming two hours of music every day, half of them using ADSL, half of them using GPRS. ¬†What’s GPRS? ¬†Oh, you know how everyone is rolling out 3G and 4G mobile phone networks? ¬†GPRS is 2G. ¬†Right, so 1 billion people are going to be using a technology that NO ONE is rolling out anymore, anywhere. ¬†Also notice that there are only two types of service mentioned here: physical network, cellular/mobile network. ¬†Did someone forget Wi-Fi? ¬†Most users not blessed with an unlimited cellular/mobile data plan (which is damned near everyone in the Americas, anyway) will opt for the much cheaper Wi-Fi in their own homes, coffee shops, schools, business, etc. ¬†This report¬†pegs the energy usage of GPRS at around 2.5 times that of Wi-Fi. ¬†I know this is an industry group for the music business, but I wonder if they get money from carriers to demonstrate the need for large government cash infusions into… carriers.


The whole report is a real trip.  If you are a policy maker, investor, or unusually gullible, I will simply advise you not to take anything in that report seriously.

Oh, you also have to subscribe to their newsletter in order to access the paper.  You can unsubscribe right away, apparently.  I will be.

Dragon ID’s mobile unlock by voice

A brief but interesting story on GigaOm.

Nuance, the company behind the Dragon family of voice recognition products, is promoting a mobile app called Dragon ID. ¬†The app acts as a replacement for standard user authorization schemes like PINs or swipe patterns by matching speech characteristics of a user against a known set of characteristics. ¬†It’s the old “My voice is my passport” idea that we (or at least I) saw in “Sneakers“; the user speaks a phrase into the device, the device checks to see if the user’s speech has the same x, y, and z as the real Mr. User, and accepts or rejects the attempt.

At first blush this looks like a UX winner. ¬†The user doesn’t have to remember any complicated passwords, PINs, or other meaningless tokens. ¬†And it would be impossible for the user to lose his authenticator, his voice, except by disease or injury.

But there are some security considerations that must be satisfied for this to be an acceptable gatekeeper for a mobile device. ¬†The most obvious weakness of this system would be to a replay attack, literally replaying a recording of the user authenticating. ¬†What countermeasures are used by Dragon ID to prevent such simple attacks? ¬†Presumably the audio recording is analyzed by Dragon ID to ensure that the voice is coming from a point directly in front of the device or headset microphone, but this would not be a robust defense. ¬†Can it detect artifacts of digital audio reproduction? ¬†Audio compression schemes like MP3? ¬†Does it emit a one-time audio watermark via the speaker during recording so that a replay would be easily detected? ¬†I’d certainly love to know.

Pattern matching is performed against an established set of phrases recorded by the user. ¬†This simplifies the task of matching a candidate audio sample’s characteristics against a known set of characteristics, but it presumably reduces the amount of work an attacker would need to put into making a passable authenticator. ¬†In a perfect world, the app would compose a unique phrase for each attempted authentication, each log-in, so that an attacker would have no real template for a “good guess”. ¬†The attacker would need to know about a user’s full range of accents, inflections, cadences, etc., in order to make a passable authenticator, and he would only get one shot at each phrase. ¬†With a known subset of authenticators (like a decent recording of one successful authentication attempt), the attacker knows what the phrase will be for any future attempt and that he will only have to polish it somehow for it to be acceptable.

Phrases can be disabled by the user or disallowed by the device or the Dragon ID servers for too many failed attempts, but this raises a question about the resistance of the app to multiple attempts. ¬†The app surely only allows a certain number of attempts before either locking the device entirely, disabling a specific phrase, or forcing the user to authenticate with a password or some other non-voice token. ¬†But how does it track multiple attempts? The app is required to work even when the device is completely disconnected from voice or data networks, so there must be some form of device-resident logging. ¬†If the device’s memory is cloned before an attack, what prevents the attacker from reflashing the device into its previous state where the counter was at 0? ¬†There are plenty of memory locations on a device to store counter information, and more clever ways than a simple variable in a LoginAttempts.dat file. ¬†Is it possible to completely reset the state of the device to a set point such that an attacker could indefinitely attempt authentication?

Enlighten me.  I love this stuff.


Original article on GigaOm.