Musings on Apple Pay

I have waited several years for Apple Pay and am glad it is finally here. What I am not so happy about it uses NFC and hence works only on iPhone6 :-( Ostensibly, this is for "security" (and there is mention of "secure storage" as well) but I question that.

Secure Storage
I think even the iPhone 3GS has reasonably secure storage to store any private keys that may be needed to generate one-time transaction authorization codes.

Barcodes, WiFi, Bluetooth
The random token can be sent to the payment terminal using a barcode displayed on the screen and still be as secure  It can use WiFi or Bluetooth as well. Barcode at first glance would appear to be a one-way channel but the phone has a camera too (in case we want the payer to check if the payee is legit, but I don't think that is done or needed for credit card payments). [Update April 2017: PayTM in India is using an NFC free solution and a 2D barcode to identify the seller]. WiFi might be tricky if a user is on a network different from the one the payment terminal wants to use and it is not as power-efficient as Bluetooth. Barcode has the advantage that existing payment terminals with Barcode readers can be updated to Apple Pay with software changes.

User Experience
One might argue that a barcode based system would be a less appealing user experience than a radio based one. However, I fail to see why Bluetooth would not achieve the same. Why did Apple choose to have another component in the system? Perhaps because there is an installed base of NFC payment terminals? I doubt that.

Why Security Matters? Consumer is not on the hook for that
We all know that we are not responsible for fraudulent charges on credit cards. That burden is borne (rightfully so) by the payment processing industry. However, they pass on the cost of fraud to merchants as high transaction fees and the merchants pass that on to consumers. By designing a system that is more secure than the physical credit card (at least those common in the US), Apple was able to convince the payment processors to give it discounts on transaction fees. Of course, it will not translate to lower prices for consumers anytime soon (sigh!) but the payment industry needs a lot of shaking up. 1-3% processing fee is ridiculously high in the electronic age.

Conclusion
I hope that Apple starts supporting Bluetooth based Apple Pay in the future because I believe it will be as good as NFC.

Plaintext passwords

I saw this (and this) and instantly thought: seems fair, if you saved the password for a site then anyone with access to the browser can log in to the site. So why not display the password in plaintext if a user wants to see it? The only reason would be to allow users to save a password for a less important site and use the same password on a more important one. That way, if someone got access to the browser they can login to the less important site but not the more important one.

The tradeoff, however, is that showing the password is a great usability feature. If I save the password, I tend to forget it and when I want to log in from somewhere else I need to see the saved one. The Chrome developers chose usability for this case. I would do the same. In fact, I would be upset if I cannot see the password when I want to see it. [Some banks don't let you see your own account number when you log in and I find that silly and upsetting.]

I think the confusion arises from the publicity given to some data breaches where passwords were not encrypted or were hashed without salt. This issue is clearly different from the browser's saved password feature. This issue is comparable to a thief getting access to everyone's money in a bank while the browser issue is more like me getting to count the money in my wallet.

Samsung KNOX - security by obscurity?

Samsung is finally getting serious about security. Most people don't realize that Apple has had it for a while. I blogged about it a few months ago. One of the cons of Apple's solution was the lack of a mobile device management (MDM) solution of its own. Samsung KNOX seems to have some part of that baked in while relying on "enterprise preferred MDM vendor solution" to complete the solution.

It is not clear to me if KNOX is as good as iOS. It is nice that the files are encrypted but that is no use of the keys are easily accessed by an adversary. It is not clear how they are stored in the KNOX design. Apple's design is good: keys are generated randomly at factory and stored securely in the chip. If KNOX doesn't get this right, there is no value in its MDM or other security features. Until Samsung documents that part openly, I would call it security by obscurity...or security by marcom (marketing communications) :-)

iOS security pros and cons

Security via obscurity doesn't stand up to the test of time. Apple has released a whitepaper providing an overview of their approach to security. It appears to be a good approach and shows that the company is serious about security because security is baked into the iOS cake and not merely included in the icing on its surface.

Pros
Secure boot chain -- Read only LLB is implicity trusted. It loads iBoot after verification which loads iOS after verification. This makes is really difficult to get untrusted code on the device even if an adversary has physical access to the phone. It is still possible if he can mess with the LLB, and I doubt if the hardware has robust resistance to physical tampering, so high value targets should not rely on this.

No downgrade -- Software downgrades are not allowed, thereby narrowing the window of opportunity for an adversary to exploit a software vulnerability to the time it takes to patch the system. Once patched, the window is completely closed.

Curation and signed apps -- Every app is reviewed by Apple and digitally signed. However, because of the size of the developer community, Apple cannot possibly check the apps to guarantee lack of malicious code. I still consider this a pro, because it does reduce the vulnerability surface(and until we get some breakthroughs in computer science theory where a program can be proven benign this is the best one can do). A user should understand that he is trusting the app developer and not Apple for 3rd party apps.

Entitlements -- Every app that requires privileged resources explicitly gets rights to specific resources. This is an implementation of the principle of least privilege and is a better option than implicitly allowing access to everything.

Erase function -- Contents are erased by erasing keys required to access them. This makes the process quick and hence more likely to be used when needed.

Random keys in flash DMA engine -- These are not known to the manufacturer or Apple. So there should be no backdoors.

Cons
Enterprise app provisioning-- It is not clear how this is handled. Can an enterprise app access personal data of the user? Can the user remove the app when he chooses to?


Erase function -- Erasing keys should be followed by actually erasing the file data as well. This will protect against attacks on the ciphertext. Assuming AES is secure is reasonable but assuming that the key generation scheme is perfect is not.

Reliance on passcodes -- Although there are delays between attempts to thwart a brute force attack, passcodes are not very secure for the average user. An adversary can see the user type the passcode, look at fingerprints on the screen to significantly narrow down the scope of the brute force attack etc.

[Apple today acquired a biometrics company, so perhaps we will see this issue get addressed in the next iteration of iOS. Hopefully, it will be available to older generation hardware as well.]

Keychain -- Apple does not allow the user to make the security vs usability tradeoff here. Most keys (like Exchange password) are available in memory after the first unlock of the phone. This allows background apps to run but there should be a way for more security conscious users to opt out of this and have the keys in NSFileProtectionComplete class so that they are erased from cleartext DRAM memory when the phone is locked.

Incomplete forward secrecy -- There seems to be no way (apart from backing up all data and erasing everything) to re-encrypt files with updated keys. Only the keys used to wrap the file encryption keys are changed. This is a problem in the following scenarios --
 1. An adversary gets access to unlocked phone and is able to retrieve the file encryption keys. The user(upon discovering this) changes the passcode thinking that any new data saved in the file will be protected. But, the file is still encrypted with the compromised key and the adversary can decrypt the file by getting access to the device.
2. A bug is found in the key generation scheme. In this case, Apple can avoid writing the re-encryption code until it discover the bug and publishes the patch.
There is a way to re-encrypt files with new keys by backing up all data, erasing everything, choosing a new passcode and restoring from backup.


Reference
http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

RSA SecureID is now 1.5 factor not 2

Everyone is trying to figure out what really happened. One theory is that there was a government backdoor. That is possible since SecureID is a closed technology and it is unclear how it works. It has not been reviewed for strength of architecture/algorithm that could cause unintentional security breach or absence of intentional backdoors.

Network World reported the following:

In its "Incident Overview," which was part of the update, RSA stated, "To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information."

This indicates that an attacker can get access to a protected system without having physical possession of the SecureID token. If that is true, the other RSA quote (from Network World)

Many are, in fact, bewildered by the statement Coviello made on March 17: "While at this time we are confident that the information extracted does not enable a successful direct attack on any of our SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack."

would mean that the "reduction in effectiveness" is basically that the authentication is no longer based on two factors. It is based on one factor (and some phishable data) only.

How is this possible?

I don't know how SecureID works but this is how 2 factor authentication works and it must do something like this:

One factor is something that you have, in this case, a hardware token. This presumably would have a private key which would be shared by the authentication server (or the server will have a paired public key). Ideally, every token would have a completely random key but RSA may have taken a shortcut and used one that is somehow dependent on the serial number of the token(or some other insecure input like customer id etc). If the attacker was able to get information that can be used to guess this key from the serial number(or other info) then he or she can succeed in authenticating without having access to the token itself.

This theory is not incompatible with the government backdoor; indeed the government may have asked RSA to use introduce the above weakness. Or it could have figured it out a long time ago on its own.

Evolution in the Data Center

Ok, this post does not have much to do with security (except for one of the points below). I've been catching up on happenings in the data center these days and it appears a gradual evolution is underway. The following is what I understand and I wrote it down so that
- you might avoid having to do the research
- more selfishly, you might point out mistakes in my understanding

1) What is virtualization -- First of all, the hypervisor has very little to do with what is happening in virtualization now. Until I figured that out (I thought virtualization and hypervisor are one nad the same; and although it is cool to be able to run multiple OS's on a CPU, one can achieve 80-90% of what a hypervisor provides without virtualization) I did not think virtualization was of much use and that is was hyped unnecessarily by the tech media. Now I realize that virtualization is not about the hypervisor (yes, it is now an important element but almost commoditized) but about tools that help IT admins to dynamically respond to changing IT needs such as:
- Provisioning new applications quickly
- Scaling them up or down to meet changing loads
- Migrating them to different servers in the same or a different data center for performance or power optimization or for disaster recovery etc.

2) Components of a virtualized data center -- To achieve the above goals the following components are needed:
- Servers -- Of course, where else would the applications run :)
- IP switches/routers -- For users to access the applications and for applications to talk to each other. If NAS is used these also provide access to storage
- Optional storage switches -- Although theoretically possible to use storage attached to servers directly, it is more efficient to use specialized storage like SAN or NAS. If SAN is used, FC and/or FCoE switches are needed.
The above components are not new. They have been used in data centers for ages. But virtualization does impose new requirements on them.
- Virtualization magic software -- This is a new and hence arguably the most important component. It is the software that allows the IT admin to orchestrate the changes needed to achieve the three goals mentioned in (1) above. This is what made VMWare successful (for a long time I thought it was the hypervisor!). Scalent makes another nice one...I am sure there are others

3) Market Dynamics -- This evolution of the data center provides an opportunity for vendors of the above components(incumbent and upstarts) to innovate within those product categories(to address the changing requirements). That will surely happen and within a year or two , I believe, all vendors within those categories will have 90% matching features with remaining 10% in a diminishing returns but unavoidable arms race. On the other hand, this evolution also provides large incumbent vendors an opportunity to innovate across categories providing vertically integrated solutions (like Cisco, VMWare, EMC). Of course, this creates an opportunity for exactly the opposite innovation: enabling standard, interoperable, multi-vendor solutions. Scalent is a good example of this. I think in the end the latter will win but it might still make sense for companies like Cisco to delay this for their products and pursue vertical integration to gain market share.

It will be fun to watch this happen!

Is SSL broken?

I was reading Network World and for a very brief moment was alarmed to learn that SSL is not secure and that Tim Greene recommends (or is he quoting the researchers opinion?) that people should not use public wifi even for SSL-safe browsing.

[Network World article says "SSL VPN..." although the threat if real should apply to non-VPN uses of SSL as well and the examples cited are for online banking and most people won't call an SSL connection to their bank an SSL VPN. SSL VPN is the extension on an "intranet" over the internet using SSL to secure it]

Then I found the this article that seems to have slightly more data. I havn't seen the demonstration but I have a suspicion that this is much ado about nothing. It seems the flaw is that if parts of the page are EV SSL and other parts are not EV SSL the browser does not complain as long as the domain is the same. (The part is bold is my assumption but if it is true, there is nothing to worry about. If my assumption is not true all hell will break loose, public Wifi or not!). I think all parts are not EV SSL because the site owner did not want to shell out extra money for EV SSL certificates for every sub-domain. This makes sense, because EV SSL is pretty much useless and I don't understand why the website got an EV SSL certificate at all!

If you read this and know that my assumption above is false, please comment and let me know. I should stop using the internet!

Update 3.11pm: Found the abstract here: http://www.blackhat.com/html/bh-usa-09/bh-usa-09-speakers.html

[scroll down to find "Alexander Sotirov, Mike Zusman
Breaking the security myths of Extended Validation SSL Certificates" ]

My assumption is valid. SSL is still secure. Their point is that EV SSL is not more secure than cheapo SSL.

"Unfortunately, it turns out that the security offered by EV certificates is not any better than the security of even the cheapest $12 SSL certificate"

We already know that is true...this is one more reason and makes it "truer", if that is possible :-)