Thursday, June 21, 2007

iPhone Lockdown and Intent-Based Pricing

There are several applications I'd want to run or port on an iPhone. This includes a full ssh environment, subversion version control, and some custom scripts using ImageMagic which would allow me to process, manipulate, and upload photographs using my digital camera (assuming you could adapt the iPod port to a camera or compact flash card) : all tasks I perform on my Mac laptop but which would greatly benefit from the greater portability of an iPhone.

Yet Apple and AT&T's lockdown policy, only Apple authorized applications can run on the iPhone, means I will be unable to use the iPhone to its potential. I understand the reasons why Apple and AT&T want this property: they want to limit applications which can run because they wish to bill for service based on intent.

At $10 for 1500 SMS message at 1 kB/message, SMS messages are worth roughly 1.2 Mb/$. With voice (beyond the first 500 minutes) at roughly $.05/minute and approximately 8 kbps, vocie is roughly 10 Mb/$. Finally, at "unlimited" data (with a reasonable limit of say 5 GB) for $20, the data traffic is 2000 Mb/$. Thus the intent of the bits, whether it is an SMS message, voice, or best-effort data, effects how it is billed. Thus AT&T's interest is to ensure that the iPhone can't circumvent intent-based billing.

Overall, there is a design philosophy which is creating a sealed box rather than an open box. The sealed box offers some better security properties (as AT&T theoretically does not have to worry as much about misbehaving iPhones), but the security properties are somewhat illusionary. Attackers will still be able to compromise the Safari implementation and gain control of iPhones. It will be difficult for attackers, but doable and highly attractive.

Additionally, the hole in the sealed box, the ability to run sanboxed Ajax-ish web applications, defeats AT&T's intent based pricing, the stated and implied security goals, and Apple's stated goal of a pristine user experience. An Ajax-ie webpage could easily interface with IM protocols, replacing high-value SMS traffic with lower value bulk-data. It is vulnerabilities in the web browser which attackers will exploit. And the interface will never be as good as a native interface running directly on the iPhone.

In the end, the iPhone is a porsche which can only turn left.

If you only ever want to do what Apple has decided you should do (namely email, web surfing, music, and a phone), it is a beautiful platform, and probably worth every penny.

If I could obtain development tools and install new applications, I would buy one in a hot second, even with the transition costs as a Verizon customer.

But with the current model of a sealed box, I will not buy one and will urge my friends and family not to buy one, at least until it costs no more than a basic phone. It may be beautiful, but it is crippled.

Personal Financial Security Protocols

Note: The following is a work in progress. Comments are greatly appreciated.

There is an old saying, "The cobbler's children have no shoes", implying that experts in a field often neglect their own discipline in their daily lives. For me, as a security "expert", this is not the case. I have a rich and complex set of personal protocols for dealing with financial matters, including protecting my bank accounts, savings, and credit cards. I deliberately designed these protocols to balance security and convenience.

I began with a simple observation: I want to minimize my costs in a security breach. And costs to me can be reduced by either preventing security incidents or ensuring that some other party, not myself, is responsible for the lost. Thus my attitude towards my credit cards, my bank account, and brokerage account are all substantially different.

Credit Cards

I am generally rather cavalier about my credit card. I happily use online shopping, and will even email my credit card number when making a reservation at a small hotel. True, I'm not going to post the number on the Web, but I won't otherwise hesitate to use my credit card and don't take any extra care in safeguarding this information.

Why? Simply because it is not my money at stake!

Until I write the check to the credit card company, it is the credit card company's money. In case of fraud, I am able to dispute the fraudulent transaction before I have to write the check, leaving the credit card company on the hook for all but $50 (in theory) or $0 (in practice). I had this occur once, with a $5 fraudulent charge, and the process of disputing the charge was painless. Rather, it is the merchants who need to take care in accepting credit cards as the merchant ultimately carries the cost of fraud.

Bank Account and ATM Cards

My casual attitude towards my credit cards is sharply contrasted by my attitude towards my ATM card. My ATM card is ATM-only, without a Visa or MasterCard logo. With a "check" card, where the transaction goes through the credit card system, all an attacker needs are the numbers on the card. In contrast, the ATM network requires the PIN number as well as the card's information.

Additionally, I only use my ATM card at a bank branch's ATM (ideally my bank's branches). And even at these ATMs, I physically examine the slot where the ATM card enters to see if someone has attached a card skimmer (a device to read the card as it is inserted into the machine). I NEVER use my ATM card at grocery stores or other stores, as there have been several break-ins where attackers have managed to capture ATM cards as well as credit cards.

Why should I care? Although the fraud protections for ATM/check cards are as good as credit cards, until the dispute is resolved it is my money that is missing, not the banks. If someone fraudulently used my credit card, the worst case would be the card stops working (and I have two cards). If someone fraudulently accessed my bank account my rent check might bounce before I found out. Thus I need to minimize the chance of a breach.

I also do not use any automated or online bill pay or online banking, except for a couple which go to a credit card. My banking and bill payments are all done in person or through the mail. There are too many bots and key logger in this world for me to trust online banking and there is significant comfort in having a real paper-trail for any potentially disputed transaction.

Finally, when I do pay my bills by mail, I drop off the envelopes in a locked mailbox rather than leaving them for the postman to pick up. It is far too easy for someone to steal some checks and modify them if they are out in the open.

Brokerage Account

The one exception to the "No Online Banking" rule is my brokerage account, as the web site provides the only effective interface for managing the account. Fortunately I only need to access it once every few months, as I follow the general economic advice of "Buy index funds and/or CDs and just let them sit" as I know I'm incapable of reliably beating the market.

I use a bootable Linux "Live" CD (in my case, Knoppix, although I need to investigate alternatives as Konqueror doesn't render properly, forcing me to manually download Firefox). I reboot my computer using the live CD so I know that my system is free from viruses, bots, and keyloggers. I then access just my brokerage account, do my necessary changes, and restart my computer. Although significantly inconvenient, I view this as necessary.

Unlike bank accounts, the laws concerning fraudulent brokerage account access are not well-enough settled for my taste. Since I have no assurance that, in case of fraud, I would not lose money, I need to prevent fraud to as great a degree possible. Thus I must be able to trust the computer I'm using, and given the perilous state of end-host security (even Mac security), the only way I can trust the computer is by booting using trusted, read-only media and only connecting to the brokerage account.

Conclusions

Building these financial protocols took me considerable thought and effort. I had to consider what were the possible attacks on my financial data and what the consequences were. In the end, it was the consequences of possible attacks which dictates my policy: if it doesn't cost me much time and money, I don't care. But if its my money on the line, I'll be very careful.

Wednesday, June 20, 2007

Intro (Redux)

A redux on my intro:

I figure that I'm enough of an egomaniac that I finally should start up a blog. After all, it is only academics with LARGE egos which should be blogging... This is not really very active yet, but I expect to use it in the future to post original items.

For background, my research area is computer security and computer architecture. I received my Ph. D. from UC Berkeley in the fall of 2003, and since then I've been a researcher at the International Computer Science Institute (ICSI).

This blog, however, will also include my thoughts on random topics of which I am completely unqualified as well as information on computer architecture and security topics.

I tried to start blogging, let it lie fallow, and am going to try to start again.