Nerdland
Thu, 26 May 2016 04:12:45 +0000
en-US
hourly
1
104322552
Impressions on the Nexus 7
/2012/07/impressions-on-the-nexus-7/
/2012/07/impressions-on-the-nexus-7/#respond
Thu, 19 Jul 2012 03:17:13 +0000
I’ve had the Nexus 7 in my hands for about twenty-four hours now, and I’ve been playing with it a lot. It’s my first tablet, so I can’t compare it directly to the iPad or earlier Android tablets, but I can say that I am very happy with it, especially for only $200.
The physical size is pretty nice. It’s definitely much more portable than a ten-inch tablet would be. I can even fit it in my front pocket. While I wouldn’t want to lug it around in there all day, it is convenient for transporting it short distances without tying up your hands. And it’s light. I don’t notice any issue with weight
Its most immediately impressive quality is just how fast it is.
I hate interface lag with an intense passion. That’s why back in prehistoric days I loathed my Razr when everyone else raved about them — the interface was, to me, completely unresponsive. While I haven’t owned any other tablets, I have tried them out in stores, and tried out tablets that others own, and I was always let down by the way Android tablets performed. Even the highest end pre-ICS tablets had noticeable interface lag, even when doing something as simple as swiping between home screens. None of that on the Nexus 7. The Android team did a phenomenal job with their “Project Butter”.
As far as the seven-inch form factor goes, I’m still a little up in the air about it. Depending on what I’m doing with it, my impression alternates between “Wow, it sure is nice to have all this screen real estate in a handheld device,” and “Hm, it just feels like I’m using a giant phone, how awkward.” I think having tablet-optimized apps makes a big difference here. Flipboard, or the new Google+ app, or MLB At Bat (which was was pleasantly surprised to find has a totally different and much better layout when on a tablet) feel very natural at seven inches. Scaled up phone apps (TweetDeck, for example) are a bit off-putting. Another part of it is the home screen interface. Android has a “tablet style” home screen and a “phone style” home screen. The Nexus 7 uses the “phone style” home screen, which re-enforces the “big phone” feeling.
I love the bigger keyboard though. My big inaccurate fingers cannot type well on a phone’s on-screen keyboard, so I always use something like Swype or SlideIT to type word-at-a-time. On the Nexus 7 I can easily type with two thumbs (in portrait orientation), or four fingers (in landscape orientation), which vastly improves my typing speed and accuracy.
So what am I using it for? So far, for reading and video. I still prefer my e-ink Kindle for extended reading of novels, but the Nexus 7 works much better than a phone for news reading (over breakfast, for example) and web browsing. It’s also a nicer size than a phone for watching Netflix, or watching the Phillies lose (yet again), when a full-size computer is not around. So I guess for me it’s falling into the slot of a device which, when available, is generally preferable to a phone, although it’s not as portable. So the phone is still best for texting, e-mail, calendar, etc. on account of its extreme portability (and data connection), but the tablet wins for media consumption, and isn’t that much less portable.
A lot of people have been making a big deal out of Google Now. I think we’ve been seeing a lot of Google Now comments in relation to the Nexus 7 because it’s the first Jellybean device that most people have been able to get their hands on. In my opinion, Google Now is awesome, but it’s much more useful on a phone than a tablet, on account of the phone being with you at all times.
Also, since I’ve so far avoided putting my corporate account on the device, I have no policy restrictions and have for the first time tried out the (relatively insecure) Face Unlock feature that was introduced with ICS. It’s a pretty cool novelty, and it works surprisingly well, except in low light. If you haven’t tried it out on your ICS or Jellybean device, you might want to.
I’m not a huge casual gamer, so I haven’t tried out too many games on it yet. I played a few minutes of Angry Birds Space and Temple Run, but I don’t have much to say about the gaming potential of the device quite yet.
But, on the whole, if you were thinking of getting a Nexus 7, I’d say go for it. You only have reason to avoid it if you already have a ten-inch tablet, you can’t spare $200, or you have an irrational hate for Android.
Disclosure: I am a Google employee, but I don’t work on the Android team, and I paid in full for my device.
]]>
/2012/07/impressions-on-the-nexus-7/feed/
0
596
Build Your Own Bitcasa
/2011/09/build-your-own-bitcasa/
/2011/09/build-your-own-bitcasa/#comments
Fri, 16 Sep 2011 16:55:11 +0000
Earlier this week I heard about a new startup called Bitcasa which is offering “infinite” secure cloud storage for a low monthly fee. Now, I’m not particularly interested in relying on a brand-new startup for all of my off-site storage needs, but one of Bitcasa’s technical claims seems to have raised a few eyebrows on the Internet. In particular, I learned from an episode of the podcast Security Now that Bitcasa claims to use exclusively client-side encryption and also to be able to de-duplicate files server-side.
Think about that for a moment, and it may at first seem impossible. How can you de-duplicate plaintext that the server never has access to? But it’s not impossible, and I wouldn’t doubt that many ways of doing this are widely known, but I did find it to be a really interesting computer science brainteaser. Here’s the problem, in my words:
Design a service that allows users to store blocks of data and retrieve them later. The service must have the following properties:
No block is stored more than once.
No more than O(1) additional space is used per user who “owns” a particular block.
No user is able to decrypt a block that he does not own.
The service could not be compelled by any authority to decrypt the blocks it stores.
Extra Credit:
No communication between users, directly or through the service, is required.
The service could not be compelled by any authority to divulge which users own which blocks.
In the Security Now episode in question, the host gave a solution which satisfied 1-4, but not 5 or 6, so I have labelled them as extra credit. If you want to try solving this problem yourself, stop reading now — my solution follows.
First, some notation and definitions. Below I will be making use of two well-known algorithms: AES, a symmetric key cipher, and SHA, a cryptographic hash. Both of these come in various flavors, but the only requirement is that the output of the SHA flavor used must be the same length as the key for the AES flavor used. So, for the sake of argument, let’s say we use AES-256 and SHA-256. I will denote an application of SHA to some data X as SHA(X). I will denote an application of AES to some data X with key K as AES(X, K).
And, before beginning, I should point out that I have no idea if this is even close to what Bitcasa actually does. I don’t even know if this method is well-known and is named after some professor somewhere. This is just the way I came up with to solve the problem as presented after I thought about it for a while.
Storing a New Block
Consider User 1. This user generates a private key PK1 which is kept secret and never sent to the service. When the user logs into the service for the first time, he creates a block list BL1, initially empty. This list will store information about the blocks he owns (details later), and its size will be O(n) in the number of owned blocks. This block list file is encrypted to CL1 = AES(BL1, PK1) and the encrypted list CL1 is uploaded to the service. This file is directly associated with the user’s account and is not de-duplicated. Since the file is linear in the number of owned blocks, the user is contributing only O(1) additional data per owned block, satisfying requirement 2, even though the block list itself is not de-duplicated. The service is unable to decrypt the block list because it is encrypted using PK1, which is never sent to the server.
Now, User 1 has a block B which he wishes to store. He computes SHA(B), the hash of B, and then uses the hash as the key to encrypt the block: C = AES(B, SHA(B)). In other words, the encrypted block C is the original block B encrypted using its own hash as the key. The user then sends C to the server, and the server uses SHA(C) as the unique identifier for the block B. Note that the server cannot decrypt C since the key SHA(B) was never sent to the server. This satisfies requirement 4.
Ownership and De-Duplication
After the block is stored, User 1 must claim ownership of the block. He does this by adding a record to the block list consisting of the tuple: <filename, block number, SHA(B), SHA(C)>. The first two elements are for the user’s benefit only; they don’t have anything to do with how the service works. The filename and block number would allow the client to reassemble the blocks into complete files with names so that they can be presented in a user-friendly way. But what’s important is SHA(B) and SHA(C). Recall that SHA(B) is the key used to encrypt B and SHA(C) is the unique identifier that the service uses for identifying encrypted block C. So what this record says is “I know that using SHA(B), I can decrypt the block identified by SHA(C)“. This is an association that is known only by owners of the file, satisfying requirement 3. The user then saves the new block list file, re-encrypts it using PK1, and re-uploads it to the server. Again, the server is unable to read the contents of this file.
If User 1 later wants to retrieve a block, he requests CL1, the encrypted block list, from the server. He decrypts CL1 into BL1 using PK1, and then looks up the filename and block number he wants to retrieve. He then requests the block with identifier SHA(C) from the server, and the server responds with C. Finally, the user decrypts C into B using SHA(B) and the original plaintext data is available.
Now suppose User 2 with private key PK2 comes along with the same block B and wants to store. He can compute the same encrypted block C = AES(B, SHA(B)) using only his local knowledge. When he tries to send C to the server, the server will notice that it already has a block with identifier SHA(C), and will not store C again, satisfying requirement 1. User 2 can then add <filename, n, SHA(B), SHA(C)> to his block list BL2, encrypt it to CL2 = AES(BL2, PK2), and upload CL2. User 2 can retrieve the original block B in the same way that User 1 did, except by retrieving CL2 instead of CL1. Note that User 1 and User 2 now share an encrypted block C on the server that they can both read, but they never had to communicate with each other, satisfying extra credit requirement 5.
Ownership Anonymity
Finally, consider requirement 6. There’s a potential weakness to this sort of system. Say that block B contained some sort of illicit materials (e.g. pirated media). You could imagine an authority taking a copy of B, computing SHA(C) and then subpoenaing the service for a list of users who own that block. Could the service comply with such a subpoena? Assuming the service is trying to protect the privacy of its users and not doing anything stupid like logging which IPs addresses sent or received which blocks, it would be technically impossible for the service to associate the block identified by SHA(C) with either User 1 or User 2. The only place in which that association exists is within CL1 and CL2, which are encrypted with PK1 and PK2 respectively, and the service does not possess these keys. Therefore, the service is not only secure, but anonymous with respect to the association between users and their data, satisfying extra credit requirement 6.
One final note: Observe that it is not a security flaw if an encrypted block C or an encrypted block list CL were to fall into the hands of someone other than their owner. These are both strongly encrypted, and nothing meaningful can be extracted from either without the appropriate keys, which are posessesed (or attainable) only by the true owners. So the service can happily respond to a request for SHA(C) with C without having to know or care whether or not the requestor is one of the owners of C. The only further security consideration woud be to ensure that a user be authenticated when uploading his encrypted block list, otherwise the service is vulnerable to a denial of service attack by means of a malicious user overwriting another user’s block list with garbage.
]]>
/2011/09/build-your-own-bitcasa/feed/
5
568
Securing My Online Identity
/2011/02/securing-my-online-identity/
/2011/02/securing-my-online-identity/#comments
Sun, 13 Feb 2011 09:15:28 +0000
The recent launch of two-factor authentication for Google accounts inspired me to re-evaluate and improve the security of the numerous accounts I’ve accumulated in my time on the Internet.
I’ve always been cognizant of good password practices. Even my very first password on AOL in 1994, while it was rooted in a dictionary word, at least had numbers at the end of it. I’ve never been so blithe as to use “password” as a password, or use things like names and dates. All of my passwords today are what most would consider “strong” passwords — composed of letters of varying case, along with numbers, and not incorporating any dictionary words. However, my password practices could still stand to use some improvement.
My biggest fault is re-using passwords. I’m not so careless as to use the same password for everything, but I will admit that, like most people, I can’t come up with a unique password for every single site I need to register with. I use a family of passwords, which amusingly enough, are all ultimately derived from a password issued to me by Geocities in 1996. I’ve added numbers, swapped and inverted letters, changed case, shifted the pattern left and right on my keyboard, etc. But in the end, all of my accounts are secured by only a handful of passwords. And having a strong password doesn’t protect me against one of those sites being compromised and having a password which is also associated with some of my other accounts fall into nefarious hands.
OpenID
The most ideal solution to all of this, for me, would be if everyone would just use OpenID already. Google is an OpenID provider, and you can use your Google account as an OpenID identity, either by using the universal endpoint:
Or, if you have a Google Profile, you can use the easier to remember URL to your profile, e.g.
/tyler.mchenry
Since I have enabled two-factor authentication on my Google account, by using Google as my OpenID provider, I have now gained two-factor authentication on every site which supports OpenID.
I added OpenID support to Nerdland for exactly this purpose. Now, you can just log in using any OpenID if you want to post comments. I even went so far as to track down and fix a bug in the WordPress OpenID plugin in order to get this to work. I associated my Google OpenID with my administrator account, and then went into the Nerdland database and altered my account so that no password whatsoever would let me in to my account on the website; I will have to use my two-factor OpenID from now on. (Of course, my account on the server that hosts Nerdland is a different story, which I’ll discuss later).
Identifying Priorities
Sadly, not everyone accepts OpenID for login. In fact, only a very few places (so far, mostly places geared towards techies) do. While I use it wherever possible, I still have to deal with the fact that for now, I will have many accounts that will be secured with just a password. So, what I did was sit down and think about what exactly the highest security priorities are for me. The answers were:
Online banking
E-Mail
Nerdland
Although it may seem counter-intuitive, even sites like Amazon which I allow to store my credit card data aren’t very high on my list of security concerns. The reason is simple: credit cards have strictly limited liability for fraud. If someone gets into my Amazon account and orders hundreds of dollars in merchandise, it doesn’t really matter that much to me, relatively speaking. I call my bank, report the fraud, get a new credit card with a new number, and that’s that. On the other hand, my checking and savings accounts have no similar protection, so it’s vital that my online banking remains highly secured.
E-Mail is another can of worms. As I said, I use a family of passwords, so obtaining my password to one site only grants access to a limited subset of other sites. But if an attacker gained access to my e-mail, he or she could request password resets from every site that I have an account on, and clean house. And that’s not even to mention the potential for impersonation. Finally, Nerdland is, of course, important to me. I don’t want the website defaced, and I don’t want the server compromised and repurposed as part of a botnet. Plus, in conjunction with the last point, I receive most of my e-mail through Nerdland, and keeping e-mail secure is a priority.
So, I made the decision to keep using my family of relatively secure passwords for most low-importance sites, and focus on securing the linchpins of my online identity: banking, e-mail and Nerdland. Before you comment about it, I am aware of things like LastPass, which could help me generate a unique password for every site I visit. I’m still considering that, but the idea of installing a third-party password management add-on in every browser I use is somewhat off-putting to me.
Improving security
Securing my on-line banking was simple. I was already using a unique password that was not a part of my standard password “family” and not used anywhere else, which I generated using GRC’s Perfect Passwords. I discovered that my bank offers two-factor authentication by sending an SMS to my phone, so I simply enabled that. I wish they allowed the use of an authenticator app instead of an SMS, since it’s sometimes annoying if the SMS takes several seconds to arrive, but SMS is serviceable.
Securing my e-mail took an extra step. For a long time, I had been averse to the idea of webmail. I preferred using desktop e-mail clients and downloading my mail over POP3 so that I would have a local copy of it. If ever I needed to access my mail remotely, I could always ssh back to my desktop computer and read it that way. But last year, I discovered exactly how much money it was costing me in electricity to leave my desktop computer on all day, even when I was sleeping, or at work, or on a trip. So, I began shutting down my computer when I wasn’t at home and awake, which meant that I could no longer read my personal e-mail remotely. This quickly became annoying, so, several months ago, I began importing my Nerdland e-mail into my GMail account, storing my e-mail “in the cloud”, where it is always accessible, and using GMail as my primary e-mail client.
While GMail itself was secured by the two-factor authentication that inspired this analysis, and while I was already importing my e-mail over SSL, my Nerdland e-mail was secured by just a password, and there was really no way to change that. So, in the interest of security, I generated a new, unique, and very long password, and changed the password of my account on Nerdland’s server to use that password instead. It’s not a password I’ll ever remember off the top of my head, but I won’t ever be using it directly either.
In fact, I don’t even use it to log in to Nerdland’s server. For a very long time I’ve used public key authentication for ssh sessions, largely in the interest of convenience. At one point, there were half a dozen machines that I’d ssh into every day, and using ssh-agent with an RSA key was the only thing that kept me sane. A passphrase-protected private key is in itself a form of two-factor authentication: the key is something you have, and the passphrase is something you know. I consider my private key to be the most important security mechanism I have, so my passphrase is very long, very strong, and is used only for the key itself, and as the passphrase for an encfs partition in which I store unique passwords that I can’t remember, such as the one I set on my Nerdland server account.
What I did do to improve the security of the Nerdland server was completely disable root login and password authentication. There is now no way for me to log into the Nerdland server with even that long random password I created; I must use my private key. I carry my private key on a USB drive in my pocket at all times, so this doesn’t prevent me from using a computer other than my normal desktop to access the Nerdland server should I need to. This drive also holds other important things such the access credentials to my Amazon S3 account where I keep my backups, as well as the separate RSA key that they are encypted with; that’s the main reason for carrying it all the time — if my apartment burns down while I’m away, I can at least get my files back.
Finally, since Nerdland is hosted on a VPS in the Rackspace Cloud, I had to consider securing my Rackspace account, too. I did the same thing that I did to secure the server account: generate a random, strong, unique password and store it in my encrypted partition. I don’t frequently log into my Rackspace control panel, so such a setup isn’t inconvenient for me.
But another thing I had to do with my Rackspace account is kill the “security question”. Security questions, as they are normally used, are a complete joke. Some sites, notably financial institutions, use them the right way, as “one and a half-factor” authentication when you visit the site from a computer that you haven’t used before. But many sites use security questions as a password recovery mechanism, which is terrible. If you can reset a strong password by knowing or brute-forcing the answer to a relatively a weak security question, then your account isn’t very secure at all. So I allowed my cat to walk across my keyboard to generate my security question’s answer. If I’m ever in the position where I’d need to recover my password, I’d rather just cancel my account and start a new one than have a back door like that hanging around.
In Review
Now, the vital parts of my online identity are protected:
My banking by a strong password and posession of my cell phone
My e-mail by a strong password and possession of my cell phone
Nerdland by posession of my RSA private key and its strong passphrase
And now I can sleep a little better at night knowing that a database compromise at a site like joes-electronics.com that I registered to buy a cable from in 2004 won’t be able to allow someone to indirectly access my e-mail, or my server, or my bank accounts.
All that’s left is to wait for more sites to either accept OpenID or provide their own true two-factor authentication, and hope that adoption happens sooner rather than later.
]]>
/2011/02/securing-my-online-identity/feed/
2
529
Nerdland is Moving
/2010/07/nerdland-is-moving/
/2010/07/nerdland-is-moving/#comments
Wed, 07 Jul 2010 22:15:54 +0000
Update 11 July 2010: The move was a lot more painless than I had anticipated, and is already done. If you’re reading this, then your DNS has updated and you are accessing the new server. Hooray! See below about user accounts if you missed the original announcement.
Sometime later this month, Nerdland will be moving. The content and URL of the site won’t change; only the hosting provider will. The new host will be a Rackspace Cloud Server. This probably doesn’t affect you directly unless you are one of the people to whom I gave a Nerdland “user account” with web hosting space and e-mail over the past eleven years. If you are one of those people, please read the next few paragraphs.
As part of the move, I’m going to take the opportunity to clean out a lot of cruft that’s been building up on the Nerdland server over the past half-decade since the last hosting change. Most of the user accounts that I provided for friends and relatives aren’t being used anymore, and aren’t linked from anywhere on the Internet, so there’s no reason to migrate them. Rest assured, nothing will be permanently deleted. I’m an incorrigible data pack-rat, so I’m of course going to archive and back-up everything, including what I don’t move to the new server. If you had data stored on Nerdland, you can always contact me in the future, and I will gladly send you a copy of your old files and unretrieved e-mail, or restore your data and account to the server.
If you do still actively use your Nerdland web hosting space and/or e-mail address, please contact me as soon as possible and tell me that, and I will ensure that all of your data is moved and set you up with an account on the new server. Otherwise, I will only be migrating data which is linked from elsewhere on the Internet (according to Google’s index) or has been accessed recently (according to the server logs).
The primary reason for this move is that there is a project that I’m currently working on (that I will post about soon) for which I am going to need a server, and the shared hosting service that Nerdland is currently running on is not up to the task. In particular, it requires custom software (which isn’t possible on a shared host to which you don’t have SSH access, let alone root access), and it requires faster response times than this frankly oversold server is capable of. But since my project’s server is not going to require all of the resources available to me on a Rackspace Cloud Server VPS instance, I figured I may as well save a bit of money by hosting Nerdland on the instance as well. Hopefully, as a result, Nerdland itself will also load and respond faster.
To be honest, I probably would have done something like this a long time ago, if only just to play with it, had I been aware of the Rackspace Cloud before last month. Until I began researching hosting providers for this service that I’m writing, the only dynamic VPS provider that I was cognizant of was Amazon EC2. Not that there’s anything wrong with EC2, but it’s minimum instance size is 1.7 GiB of memory and 160 GB of disk space, which is far more than I would require for experimentation or a personal project, and it comes with a price to match. Rackspace’s VPS instances can start as small as 256 MiB of memory and 10 GB of space, at very reasonable prices, which will allow me to pay for more as I need it without having to lay out a fortune just to start.
Aside from having the resources I need to host my project and my website, it will be a lot of fun to have root access to an always-up server with a fixed, public IP once again. It already reminds me of the bad old days of the late 1990s and early 2000s, when I hosted Nerdland from Osric, a spunky little computer under my desk connected to the @Home Network (I still remember the IP: 24.3.98.206). Before @Home collapsed and I lost my static IP, I experimented with installing and running just about every sort of server under the sun on that dusty old box.
Dynamic DNS just wasn’t the same, and these days, electricity costs alone make it a bit silly to run a separate computer on a consumer-grade broadband connection rather than just paying for a real server. So finally, with the advent of affordable cloud-based VPS hosting, I can regain all the benefits of a real server once again. And now that I’m a more educated and accomplished programmer, I can instead experiment with writing my own software to run on my shiny new (virtual) box.
]]>
/2010/07/nerdland-is-moving/feed/
3
511
“Code”: Mass Noun versus Count Noun
/2010/06/code-mass-noun-versus-count-noun/
/2010/06/code-mass-noun-versus-count-noun/#comments
Tue, 15 Jun 2010 17:45:37 +0000
In English, there are generally two ways of describing quantities: mass nouns, and count nouns. Count nouns are used when the quantity in question is a set of discrete items. “There are twelve bananas.” Here, ‘bananas’ functions as a count noun, which is appropriate because you can clearly tell where one banana ends and the next begins. In contrast, mass nouns are used when the quantity is continuous and not divisible into countable units. “There are twelve peanut butters,” for example, does not make sense. What constitutes a single “peanut butter”? Unlike with a count noun, a unit is required to refer to a specific quantity of a mass noun, even if the unit is implicit, such interpreting the previous example to mean “There are twelve jars of peanut butter.”
This brings me to the word “code”.
Used in its computer programming sense, “code” is always a mass noun in English: “I stayed up writing code until midnight.” “I had to read through four thousand lines of code to find the bug.” “Dammit, what is wrong with all of this code now?” Code is thought of as an continuous mass. Code is what you pour into the engine of your computer to make it run. Aside from the very first few instructions that run as part of your system’s bootstrap, no code stands alone, and you can’t divide code without encompassing it in some larger concept. You can have “two programs” but you can’t have “two codes.”
This sense of the word “code” likely derives from the older sense in which “code” is a synonym for “protocol”, or “structured communications mechanism”, e.g. “Hamming code“, or “Morse code“. Code is the protocol which the programmer uses to communicate with the computer. It has a usually rigid syntax, and its purpose is to give the programmer a mechanism for specifying what he or she wants done in a manner that a dumb box of circuits can make sense of. Code is a series of very clear, unambiguously meaningful instructions.
But the word “code” has other definitions. One is a synonym for “laws” or “rules”, but the other, as listed in Merriam-Webster online, is
3 b: a system of symbols (as letters or numbers) used to represent assigned and often secret meanings
Of all the meanings of the word “code”, this is the only one that functions as a count noun: “What is the code to open this lock?” “During World War II, British spy agencies cracked dozens of German codes.” “The teenage girls devised four different codes to use in passing notes.”
This is why it always disturbs me just a little when I read programming questions or discussion in which someone uses “code” as a count noun: “Please send me the codes.” “What are the codes for displaying a context menu?” “What is wrong with these C++ codes?” I’m sure many of these are simply non-native English speakers who are doing their best to work in this baroque tongue of ours, but I can’t help but shake the feeling that some of these people are native English speakers who are conflating the two senses of the word “code”.
The reason that this disturbs me is not because it’s some grammar peeve of mine. Rather, I suspect that native or fluent English speakers who use “code” as a count noun are subtly revealing their perception of code as something secret and unknowable. For example, the aspiring programmer who asks “What are the codes for displaying a context menu?” might be thinking that there is some particular set of magical incantations hidden somewhere in a dusty, forgotten tome which need to be recited precisely in order to conjure up a context menu. Similarly, one who requests that I, “please send [him] the codes,” is more than likely not interested in understanding how to accomplish the task he is asking about, but is instead interested in obtaining what he sees as an opaque sequence of characters that, when compiled, will make the computer do what he wants.
In short, the use of “code” as a count noun, rather than a mass noun, and when not explainable by imperfect mastery of the English language, is a potential red flag for impending cargo cult programming (which I consider one of the biggest issues in Computer Science education, and have complained about before).
]]>
/2010/06/code-mass-noun-versus-count-noun/feed/
3
506
Understanding the Five Aspects of Cryptographic Security
/2010/03/understanding-the-five-aspects-of-cryptographic-security/
/2010/03/understanding-the-five-aspects-of-cryptographic-security/#comments
Thu, 11 Mar 2010 18:00:28 +0000
Encryption on the Internet has come a long, long way from the oft-ignored little yellow key in the lower left corner of your Netscape Navigator status bar. Today, cryptography is a vital part of all of our Internet lives, whether we realize it or not. Now, if you’re reading this article on Nerdland, chances are that you’re well aware of that, and I don’t need to explain why you need to be sure your online banking is done over an HTTPS connection, and why connecting your laptop to an open, unsecured wireless network is usually a bad idea.
But the little stuff can trip you up just as easily, and if you don’t have a solid understanding of the different facets of cryptography, you may well think that a system meets your security requirements when it does not. After all, modern cryptography is just mathematics. There’s no inherent application for it. Security isn’t a tangible property either; it’s an umbrella term for a whole class of goals. Rather, privacy, authentication, identification, trust, and verification — mechanisms of applied cryptography — are what provide the most commonly desired types of security. Understanding what these terms really mean, how they are implemented, and how they are different is essential to a true understanding of how encryption works to assure your security on the Internet, and even within a single computer.
This article assumes you are familiar with the fundamentals of cryptography: that you know what constitutes encryption, that you know what a key is, and that you know the basic difference between symmetric key cryptography and public key cryptography. I am concerned with describing and clearing up some misconceptions about the practical applications of cryptography to modern computing.
1. Privacy
Privacy (or “secrecy”) is the cornerstone of applied cryptography. A commonly desired form of security is making data readable only by certain intended recipients. Whether symmetric or public key cryptography is in use, a person (or machine) proves that they are an intended recipient by possessing the key that can be used to decrypt the message. In the case of simply achieving privacy, it really doesn’t matter whether symmetric or public key encryption is used; public key encryption is very slow, so in practice, it’s only used to encrypt a symmetric key that is used to encrypt the rest of the data.
Privacy is commonly desired when sensitive data is being transmitted. In the case of web browsing, this is one of the purposes of the Secure HTTP (HTTPS) protocol. When communicating with, for example, your bank’s website, it is important that the information being transacted is private. It is highly undesirable for any other person, even a professional network administrator at your ISP, who happens to control a computer on the Internet through which the data between you and your bank passes, to be able to look at your account numbers and balances.
Similarly, if you store sensitive corporate information or highly personal documents on a laptop, you would want to make sure that these documents remain private if the laptop were ever lost or stolen. For this, you would encrypt the files (or better yet the entire hard drive) and either keep the decryption key outside of the laptop, or keep it protected with a strong passphrase. In the latter case, the passphrase itself is the key to a cryptographic algorithm will provide the unencrypted version of the decryption key for your files or hard drive, and the passphrase is ideally stored only in your head.
This is privacy: no third parties can read your data. No more, and no less. A common problem is that users, even technically savvy users, often make the false assumption that privacy implies authentication and verification. While the ability to create privacy is a prerequisite for authentication and verification, and they are often used in conjunction, it is not the case that obtaining privacy implies that the other two types of security have also been obtained.
2. Authentication
Authentication is the act of proving who you are, or challenging someone else to prove who they are. The underlying technology for modern authentication schemes is public key cryptography. I said earlier that I was assuming familiarity with public key cryptography, but let me reiterate the most salient aspect of it for the purposes of authentication: In public key cryptography, only Alice’s private key is able to decrypt messages that have been encrypted with Alice’s public key, and only Alice’s private key is able to create encrypted messages that can be decrypted by Alice’s public key. Specifically, a message encrypted with any other private key will produce different (usually meaningless) unencrypted data if Bob attempts to decrypt it using Alice’s public key.
The fundamentals of authentication consist of a challenge-response exchange. If Bob presents (“challenges”) Alice with a piece of arbitrary data, and Alice responds with a piece of encrypted data that decrypts to Bob’s original arbitrary data when decrypted using Alice’s public key, this proves that Alice possesses Alice’s private key. Nobody else other than the person who possesses Alice’s private key (presumably only Alice) could produce encrypted data that would decrypt back to Bob’s initial data using Alice’s public key. If Bob presented Mallory with arbitrary data, and Mallory wanted to impersonate Alice, he could not; without Alice’s private key, he would not be able to produce the expected response that Bob was looking for.
It is clear from this, however, that authentication is only useful if you already know the public key of the person you are hoping to communicate with. One common application of cryptographic authentication on computer networks is Secure Shell (SSH) logins. Commonly, a user will install his or her public key on a server that they wish to log into via SSH, and will keep his or her private key on a personal machine. When logging into the server, the server challenges the client to prove that it holds the private key corresponding to the username that the client is trying to log in as. If the client satisfies the challenge with an appropriate response, the login is allowed without requiring a password for the user.
This is more secure and often more convenient than prompting for a password, since the private key is much harder to steal or guess than a password, and the same public key can be used on multiple servers with none of the security risks that apply to re-using the same password in multiple places. The same sort of thing can be done with web servers using something a little more complicated called a client-side certificate (see below about certificates), although these are uncommon on the public Internet and more often used on corporate intranets.
This is authentication: you can know with certainty who you are talking to. That is all; no more, no less. Note that this carries no implication of privacy. It is perfectly possible to authenticate your counterpart in a conversation and then proceed to have a non-private conversation. That wouldn’t be a common choice, but there’s nothing that prevents it.
More importantly, it is perfectly possible to have a private conversation without authenticating your counterpart. This is where a danger of a false sense of security lies. Bob could be talking over a perfectly private, encrypted connection, but if the person on the other end is Mallory and not Alice, Bob would never know that he is sending his sensitive data to, or receiving critical information from, a different and potentially malicious person.
In other words, just because you are sending your credit card number over a private, encrypted connection, doesn’t mean you aren’t unknowingly sending it directly to a criminal.
3. Identification
Identification is the aspect of applied cryptography that addresses the flaw in the above-described authentication process wherein you must know a priori the public key of the person you wish to communicate with. Perhaps surprisingly, this is the most complex common application of cryptography to security. If Alice and Bob wish to authenticate each other over the Internet, they must first exchange public keys. But they can’t just send them to each other over the Internet! If Bob received a message that purports to be from Alice and to contain Alice’s public key, he has no way to authenticate that the message actually came from Alice (and not from Mallory pretending to be Alice) without already knowing Alice’s public key. It’s a chicken-and-egg problem.
The direct solution to the problem is for Alice and Bob to exchange public keys off-line; to meet at Starbucks and hand each other CDs with their respective public keys on them. But this is not practical if Alice and Bob live thousands of miles apart, it is not practical if Alice is a banking institution and not a person, and it is still not practical if Alice and Bob do not already know each other.
If Alice and Bob are strangers (but still wish to authenticate one another) meeting to exchange CDs at Starbucks still, even if physically feasible, still isn’t secure. Mallory could show up at Starbucks a few minutes before Alice and, pretending to be Alice, give her public key to Bob, and now Bob will authenticate Mallory as Alice in future conversations. A way to fix this loophole is to have Bob check Alice’s driver’s license before accepting the CD. This is identification: you can know that a public key purporting to belong to a particular person or entity actually does.
Now, meeting in person and checking driver’s licenses is a human solution to a computing problem. There are of course computer-based solutions to this same problem that will also avoid the impracticalities of first having to meet in person with everyone whom you wish to authenticate later. But these solutions are based on the same principle as the driver’s license check: trust. The reason that Bob is willing to accept Alice’s driver’s license as proof that Alice is who she says she is because Bob trusts that the state government would not issue a license in a false name or with a false photograph (ignoring for the moment the possibility that the license itself is a fake and not issued by the state). Computational identification is based on the same notion of trust.
4. Trust
Ultimately, to accept that a public key belongs to the person it claims to, you must trust that it does. Trust can be simple, if for example the key was given to you in person by your friend Charlie who you are sure is not being impersonated by a shape-shifting alien. Trust can also be more indirect. If Charlie gives you his brother Dan’s public key, and you trust your that Charlie is honest and has good reason himself to trust that the key legitimately belong to Dan, then you can accept Charlie’s assertion that the key belongs to Dan as identification of Dan’s public key.
Computationally, this identification process is based on signatures and certificates. A certificate is like a driver’s license: it identifies a public key as belonging to a named individual, entity, company, or organization. The fundamentals of a certificate are simple. The person wishing to be certified generates a file with their identifying information (in a standardized format), and appends to it their public key. That’s all. But, of course, this certificate is worthless without trust. If a stranger just handed me a card saying “I am Alice, my public key is …”, I would not accept that as their identification, would you?
To be worth anything, certificates must be signed. I’ll get to the mechanics of signatures in the next section, but suffice to say that the goal of a cryptographic signature is to use a private key to produce a non-forgeable endorsement. If Dan produces a certificate for himself, and Charlie signs the certificate using his own private key, this functions as an assertion by Charlie that the contents of Dan’s certificate are accurate. Then, since I already trust my friend Charlie, Dan can simply present me with the signed certificate containing his public key to identify himself to me. I can check Charlie’s signature against Charlie’s public key (which I already have), and from that know that Charlie asserts that Dan’s certificate is accurate, and therefore that Dan’s purported public key actually belongs to him.
This is trust: you can know that a public key belongs to who it purports to by means of endorsement by a third party. What’s important is that this can all be done without ever actually contacting Charlie, beyond once to obtain and identify his public key in the first place.
Further yet, let’s say that Erin presents a certificate with her public key to me and this certificate is signed by Dan. If I trust that Charlie would only sign Dan’s certificate if Dan himself were trustworthy, then I can trust that Erin’s certificate is valid as well. This sort of peer-to-peer trust acquisition, where an identity certificate can be signed by any number of other individuals who trust the holder (with varying levels of expressed trust), is known as a web of trust, and is commonly used for personal communications amongst security-sensitive Internet users.
But most Internet users never encounter a web of trust explicitly, and don’t really need to know how it works. What they do encounter frequently, however, is the similar notion of a public key infrastructure. This is used to establish Secure HTTP (or, more generally, TLS) connections. When establishing a secure connection to, say, Bank of America, it really does no good just to make the connection private. You must authenticate that the server you are communicating with really does belong to Bank of America. The server will send your browser its public key for authentication, but in order for the authentication to mean anything, the public key itself must first be identified. To facilitate identification, the server will send you a certificate.
In order to be identifiable, the certificate will be signed by a “certificate authority“. A certificate authority is a company who sells certificate endorsements and who has the responsibility to do whatever is necessary to assure that the contents of the certificates they are signing is truthful. Part of this process may be to ask for a faxed-in copy of a driver’s license, or to call the company’s well-known phone number and check with their IT department. The price of the endorsement can itself be a means of ensuring that an applicant is not fraudulent; a large company will have no problem paying over a thousand dollars annually for an endorsement, but to a small-time impersonator, this might be prohibitive.
A public key infrastructure (PKI) differs from a web of trust in two major ways. First, in a PKI, a certificate is signed by only one endorser, while in a web of trust a certificate may have multiple endorsers. Second, while in a web of trust a user is interested in tracing the endorsement chain back to someone that he or she knows personally, in a PKI the browser is interested in tracing the endorsement chain back to a “root” Certificate Authority. What makes a certificate authority a functional “root” in the context of HTTPS is that the root authorities’ certificates and public keys are pre-installed in the browser, and signed only by themselves. And so, ultimately, you are trusting that the manufacturer of your browser (Microsoft, the Mozilla foundation, Apple, Google, Opera, etc) is pre-installing root certificates only for trustworthy certifying authorities.
By now, you should know enough about privacy, authentication, and identification to understand what those HTTPS certificate error messages you receive from your browser mean. A browser error or warning message about an HTTPS certificate almost always indicates that a problem was encountered while attempting to use the certificate to identify the remote server (the actual authentication or encryption of the data almost never fails). The most common errors encountered are that a certificate has expired, or that a certificate’s chain of endorsements cannot be traced back to a known root certifying authority. A special case of the latter is a self-signed certificate, which is not signed by any certifying authority, root or otherwise.
These errors are important because they mean that the certificate presented by the server cannot be trusted as identification. You should afford them the same level of trust as identification that you would afford the “I am Alice” card that was handed to you; that is to say, none. And without identification of the public key, any authentication you attempt to perform on the remote server is equally worthless. The person handing you the “I am Alice” card could easily be Mallory and you would never know the difference. Note, however, that this says nothing about the compromise of privacy.
An HTTPS (or TLS) connection using an expired, self-signed or otherwise untrusted certificate allows for private communication, but does not provide authenticated communication.
That is, your data is protected against third-party snoopers on its transit through the Internet, but it is most certainly not protected against your counterpart being a malicious imposter.
I took so much space writing about trust and certificates largely to get to that point, because it is perhaps the most widespread and dangerous misconception about cryptography on the Internet. It is perfectly possible to have a cryptographically private conversation with a cryptographically unauthenticated, unidentified, and untrusted server. Just because you have obtained the “privacy” form of security does not imply that you have all of these other forms of security that you may also desire, so you shouldn’t assume that you do.
5. Verification
This will almost seem like a post-script considering how simple it is compared to identification and trust, and really it should logically appear between identification and trust, since it is the basis for signatures, but I didn’t want to break up the narrative.
Above, I glossed over the fact that a person (in a web of trust) or a certifying authority (in a public key infrastructure) is able to endorse a certificate by “signing” it. But what does that mean, exactly? Cryptographic signatures provide verification, the final common form of cryptographic security in modern computing.
Suppose that Bob writes a will leaving half his estate to Alice and half to Charlie, and disinheriting Mallory. Suppose then that Mallory sneaks into Bob’s home office, finds his will in his desk drawer, and modifies it such that it now leaves the entire estate to Mallory and disinherits Alice and Charlie. When Bob dies and the will is read, how can the executor verify that the will is what Bob wrote and has not been tampered with? In this non-computing situation, the will will have been signed by a witness or a notary public, and the executor will trust the witness or notary to inform him if the document differs from the document that they signed.
In computing, things work essentially the same way. If an e-mail (or do