Cognito based credentials finally refreshing

It turns out I had it wrong all along. See here's the flow:

• Cognito is mapping an identity to a STS based role
• We need to ask Cognito to refresh the credentials directly (not just the provider refresh)

Now, there is some debate as to whether this part of the SDK is obeying the refresh contract. So, for now I have this construct in the 'flush to kinesis' flow:

    if (self.credentialsProvider.expiration == nil |  self.credentialsProvider.expiration.timeIntervalSinceNow < AppDelegate.CREDENTIAL_REFRESH_WINDOW_SEC) {

            let delegate = AuthorizeUserDelegate(parentController: self.viewController)

            delegate.launchGetAccessToken()

            NSLog("refreshd Cognito credentials")

  }

This winds up trigger the usual Cognito flow. And if a persistent identity is in the app, then this finally does the right thing. Simulator based transmit now does token refresh reliably over many hours, or many versions of STS tokens.

Also, this version of the code is updated based on the release versions of Xcode 7, iOS 9 and watchOS 2. Everything is running fairly smoothy. There are still a couple of areas I'm investigating:

• The WCSession:sendMessage seems to get wedged in a certain sequence. Watch sends a message, is waiting for a reply, phone gets message, then watch goes to sleep. The phone has processed the message and is blocked on the reply to the watch. This doesn't seem to get unwedged any way other than waiting for a 2 or 5 minute timeout.
• This particular code does get into an initial block state if the phone is locked. This looks to be something where the accelerometer sensor needs to check with the phone to see if user has granted access to sensor.

Both of the above are a bit more than minor inconveniences. The first means that even IF living with the watch app going to sleep often, you still can't reliably transfer a bunch of data to the phone using the sendMessage method. The second means it is not clean for starting the app on the watch when the phone is locked or out of range. Maybe there is a reason. But really, we are at a point where getting the sensor data out of the watch for anywhere close to near-realtime processing isn't yet realized.

Sensor: running well on iOS 9 Seed and WatchOS 2

I've made a checkpoint of the sensor code that corresponds to the iOS9 GM seed and WatchOS 2.0. The release tag is here. Note, this code is configured to generate synthetic data, even on the hardware. I'm using this to prove the robustness of the Watch -> iPhone -> AWS connections across noisy connections.

I've cleaned up the transport a bit to send JSON directly from the Watch. This goes across the WCSession to the iPhone.  The iPhone does parse the data to examine it and update it's engineering display. But, really this raw JSON payload is sent directly to Kinesis.

Here's a screen dump of a AWS Lambda parsing the Kinesis flow. This Lambda simple prints the JSON, enough to show what is being sent:

This code runs pretty well in background mode on the iPhone. The data flow continues even while the phone is locked, or working on another application. This key concept shows iPhone as a buffered proxy to AWS.

Next up, handling a few error cases a bit better:

• When the watch goes in and out of range
• When the phone goes in and out of being able to reach AWS
• And of course, when the watch goes to sleep (real goal is to keep being able to dequeue from CMSensorRecorder while watch is asleep)

Account Break-in and the eMail Weak Link

Last week, a relative's bank account was drained. In this case a person presented some checks, in person, to a teller at the bank. The teller performed a fraud check by calling the telephone number on record for the account. The person who answered the telephone confirmed the checks were valid. Then the bank cashed the checks. Disturbing? Commonplace!

I spend a lot of time working on computer security for my day job. We spend great amounts of time on threat analysis, process control, fault detection. The world isn't very far along with respect to full protection.

So, let's dig into a particular sequence of events that likely happened here:

• Someone was able to gain access to the eMail account for the relative
• Next, they examined the eMail history (e.g for bank account #)
• Next, they requested a password reset for the bank account (sent to the email)
• Now, with access to the bank account, they:
• Examined signature on some of the online facsimiles of recently cashed checks
• Altered the contact telephone number for the bank account
• Deleted any account-changed evidence that was emailed to the relative
• Next, they prepared a counter check (readily available) and went to the bank
• The banker called the fake number and approved the transaction

Yes, the bank will accept liability and will (eventually) return the money. However, this scenario isn't quite like credit-card fraud. Here is a case where your real bank account has no money, you are stuck until the bank restores the funds (after their additional check to make sure you aren't part of the ring!)

Mobile phone eMail Weak Link

The break-in got me to re-visiting my assumptions about eMail and if there is any way to improve eMail password recovery plumbing. How good are eMail provider's MFA solutions? How big is the risk when MFA tokens and email might be on the same phone? How easy is it to social engineer a password recovery? Two cases in point:

Yahoo eMail

• Has a multi-factor solution that binds a special code to a particular system
• However, allows for a single password that binds to a mobile device
• Allows for SMS or alternate eMail address for password recovery

The problem here is that if a phone is stolen, both the SMS target AND the email address are on the same system (always have your phone go to lock mode). Also, if the password recovery email is compromised, then it is likely possible to recover a password for Yahoo (this is exceptionally easy these days as emails correlation databases are readily available).

So, one solution is to not have an SMS recovery for Yahoo and then to have the recovery email to another service (say gmail).

Note, even though SMS target can be removed for Yahoo, they really want an SMS target, they will re-ask for one during recovery even if you only want to use recovery email. So, be careful letting an SMS recovery leak back in to your configuration.

Google eMail

• Has a time based token option for 2nd factor
• This does NOT work when using an embedded email system (like on a phone)
• Has a fancy password recovery mechanism that may be a little too fancy
• Seems to ignore registered SMS as recovery option

Even if you remove the email recovery email, and only have SMS, google sort of forces you through the social password recovery scheme. I was able to get a recovery password sent to an old email address. I guess this isn't really a scientific test as I didn't try this from different IP addresses, etc. Still this seems a little to fancy (read: tries to reduce the number of support calls google gets...)

Also, here again, if both Yahoo and gmail are on the same phone, it is possible to recover both (again, hope your phone's lock system is robust)

What Next?

I'll discuss malware proxy risks in a future posting. In the mean time, need to investigate which financial institutions allow for:

• Requiring token based MFA
• Have non-email based password recovery schemes
• Optionally, restrict remote financial transactions to non-internet
• Or, allow for voice confirmed shared secrets ("what is the answer to question 2?")

Yes, the convenience of just typing in a password should be a thing of the past. But, even an MFA solution, or alternate channel password recovery doesn't seem to close all the gaps.

CMSensorRecorder data reliably flowing to Kinesis

I've refactored the iPhone side of the code a bit to better represent background processing of the sensor data. The good thing is that WCSession:sendMessage handles iPhone background processing properly. This is at the expense of having to handle reachability errors in code. The checkpoint of code is here.

Now the flow is roughly:

• On Watch
• CMSensorRecorder is activated and is recording records locally regardless of the application state of the Watch
• When the sensor application is in the foreground, a thread attempts to dequeue data form the recorder
• And when this data is received a WCSession:sendMessage is used to send the data to the iPhone in the background
• Iff a valid reply comes back from this message, the CMSensorRecorder fetch position is updated to fetch the next unprocessed sensor data
• On iPhone
• A background thread is always ready to receive messages from the Watch
• Those messages are saved to a local Kinesis queue
• A timer based flush will submit this Kinesis queue to AWS
• AWS credentials from Cognito are now manually refreshed by checking the credentials expire time
• The send and submit kinesis calls are now asynchronous tasks

So this is pretty close to continuous feed on the iPhone side.

Some areas of durability to re-explore next:

• How to build a Watch dequeue that can run when the application isn't in foreground?
• Is there another way for WCSession to send to a background task other than sendMessage?
• How reliable is the sendMessage call?
• When the iPhone is out of range
• When the iPhone is locked
• When it is busy running another application
• I do see some transient 'not paired' exceptions when sending volume
• While this does allow for automatic background processing, is there a simpler way of transferring data that doesn't require the application handling reachability errors?
• How reliable is the Kinesis send-retry when the iPhone can't reach AWS?

I will next be building more quantitative checks of the actual data sent through the system to understand where data get sent more than once, or where it is lost.

Xcode 7 beta6: Bitcode issues between WatchOS and iPhone solved!

Getting there!  A quick upgrade to Xcode 7 beta6 fixed this issue.  We now have data transfer from Watch Accelerometer to CMSensorRecorder to Watch app to iPhone to Kinesis -- yes data is flowing, mostly resiliently too; with intermittent focus, connectivity, etc.  Here is the code.

And some screen dumps (explained below):

The Watch screen dump is pretty much as before.  You will see the Cognito integration (using Amazon as an identity provider).  The first 4 lines are the identity details.  The next 4 lines are information regarding the Kinesis storage, the STS token expire time, the amount of local storage consumed, how many flushes to Kinesis have occurred, and when.

Of course the current code still relies on these transfer operations being in focus, an ongoing area of research as to how to make this a background operation on both the Watch and on the iPhone.  But still, real data is finally in Kinesis.

TODO: build an auto-refreshing STS token, as this appears to be a known problem.

Next up, write an AWS Lambda function to read from Kinesis, parse the records and then put them into DynamoDB.  Once that is there, a visualization example both on iOS and on a Server-less web service...

Marketing: make something look like what is intended, not what it is

Well, this has been a depressing past couple of days. This was the time to re-integrate the AWS SDK back into the application in preparation for sending data to Kinesis. I had basic Cognito and Kinesis hello world working back in June on WatchOS 1.0. I'd mistakenly assumed that some sort of compatibility over time would be in order. Not to be the case. Summary:

• Starting with beta5, mandatory enforcement of TLS1.2 network stacks (this negotiation fails with the current AWS SDK calls to their cloud services)
• bitcode enabled applications are required (the current AWS SDK doesn't support this)

Yes, it is possible to disable the enforcement of the TLS1.2 requirement. And this I did, I am able to get a set of temporary keys for calls to AWS services. How many applications are going to have to do this? All of them?

Worse, it doesn't look possible to use the current AWS SDK with a Watch application. This looks like a pretty ugly show stopper:

• 3rd party library doesn't have bitcode support. While you can disable this on the iPhone,
• Watch and iPhone have to have the same bitcode support level. And the Watch requires bitcode enabled.

Think about what this means!  7-8 years worth of iPhone 3rd party library support out there and probably used by a few applications. And these libraries will NOT work with any application that wants to bundle with WatchOS 2.0. The proverbial 'what were they thinking?' comes to mind.

So, I'm stuck: can't integrate with 3rd party library until rebuilt...

The calendar looks rough for Apple:

• September 9th announcements; WatchOS2 and some new hardware
• Then they turn on the holiday season marketing; "buy our watch, it has apps"
• In the mean time, a mountain of developers are trying to figure out how to ship anything on the Watch
• New message "trust us, our developers will eventually catch up"

WatchOS 2.0 beta5: development productivity increases!

I've been trying to characterize a beta5 issue where the CMSensorRecorder system doesn't reliably dequeue. There is some combination of being on the charger and then off and then starting a new debug session where the thing just works. For now, juggling with the Watch on and off the charger along with the occasional restart of debugger and I've managed to get 10 or more debug sessions. Ridiculous productivity tonight! The result is some progress on understanding how the system works.

As of now, the sample program:

• Can kick off the CMSensorRecorder for a defined number of minutes
• When the Watch application is in foreground, it will dequeue whatever records are found and then send them to the iPhone
• The iPhone will dequeue the records and test them for consistency by looking for gaps in the sensor record date stamps.

Here is what the displays look like now:

Above, you will see the new gapError count. This is a consistency of data check; a quick check to ensure that all data is sequential and updating at 50Hz (the count of 1 is expected; the first element since program launch).

Updated code is here.

Next up is to plumb AWS back into the rig to send this data to Kinesis...