Saturday, April 2, 2016

Two wheeled robot

Got started building a simple ultrasonic avoidance robot for my daughter.
  • Chassis and motors came as a cheap (as in inexpensive) kit. A great video showing how to put it together is here:
  • describes the wiring of an L298n motor controller to the motors in the kit and an Arduino.
  • Code is supplied on the above page, and is also available here:

Today I just built that chassis and started looking into how to use the L298N. Need to order some headers and other parts before I can make any progress.

Monday, February 22, 2016

Solving the Apple/FBI iPhone Privacy Dilemna

The Solution (in Brief)

Apple is right: they can't build security products with backdoors that allow the FBI to gain access anytime they want,  as that would render the security of a device like an iPhone useless. The FBI is also right, in that they can have, at times, a legitimate need to look at the data associated with certain accused and convicted persons, to aid in securing our nation and protecting its citizens.

Both parties being right, compromise is required. The short answer is for Apple to record and store the passcodes generated by iPhone owners in a secure manner, and to require the FBI to obtain a search warrant to gain access to passcodes it wants. This post describes the rationale behind such a compromise, and why it can work in more detail.


I'm a computer scientist, not a lawyer. Enough said.

The Problem

Recently, the FBI and Apple have clashed on the issue of security and privacy. This came about because the FBI, in search of data related to the mass shooting in San Bernardino, CA ( is understandably interested in gaining access to the content on the iPhone of one of the deceased suspects, Syed Rizwan Farook. Apple, for its part, prides itself on making encryption a part of the iPhone operating system, iOS. Users can enable this encryption by securing their phone with a passcode.  This article ( describes how to enable a passcode, and if you haven't secured your iPad or iPhone with a passcode, you really should do it now.

The FBI is, as I mentioned above, understandably justified in wanting to see what is on that phone. The FBI is only doing its job, trying to understand all they can about the suspect and his communications; the need to follow all leads in an investigation like this is not one that is new to the digital age. It reminds me of the efforts of Alan Turing, and others, that allowed allied forces to peer inside the Nazi Enigma devices in World War II (, and the related efforts of Magic project to crack the Purple codes (modified versions of Enigma) used by the Japanese to hide their communication while at war with the United States and its allies ( History states that being able to decrypt the messages being sent by the Japanese was critical to defeating them in World War II. Without advance intelligence betraying the plans of the Japanese forces, we would have lost at Midway due to being technically outnumbered in terms of naval vessels, the result of the bombing of Pearl Harbor which severely crippled the US fleet.

Apple, for their part, is equally "in the right". People's lives are essentially stored on their phones. Online banking, e-mail communication, personal notes and photos are stored on these devices. In the wrong hands, the compromise of this data could lead to identify theft, extortion, and a host of other problems. Customers, rightly so, demand that a device as vulnerable as a mobile phone, carrying such sensitive data, be protected from prying eyes should it ever be lost or stolen.

The protection afforded an iPhone comes from technology that at its core is really no different than the technology that was used by the Germans and Japanese in World War II. But times have changed. The technology of WWII was quite weak, and teams like those that broke Enigma and Purple stood a chance of decoding messages because of the primitive nature of encryption employed during that era. Mind you, bright people had to be involved in cracking these codes, but it was very possible. That is no longer the case, much to the dismay of the FBI.

Encryption in Simple Terms

Let's define the basic task of encryption. Encryption is inherently a simple to understand concept: take a message, or image, or text file, or anything else that is stored on a computer, and re-write it in a way that makes it infeasible, without possessing a secret "key", to convert it back to its original, unencrypted form.

Assume we have a key, unique to each iPhone and/or user, and a message to encrypt (for example, the words "My boyfriend is out of town, let's meet tonight for a rendezvous"). To encrypt the message, the key, and the message, are given as inputs to special software (or hardware) which is designed to perform the task of encryption. The software takes the key, and the message, and combines them in a way which transforms the original message into seemingly unrelated text, such as "sdfds88kjcmnvkasdd34x". If a thief (or the FBI) were to get ahold of my phone, and look inside, they would need to decrypt this nonsensical content in order to get the original content back. But they can't do that without the key, and this key is protected by a passcode. This is what makes the iPhone essentially secure, and what makes the need to use a passcode vital.

But couldn't the FBI just work to determine the key, just like the allied forces did in World War II to crack the German and Japanese codes? Assume for the moment that the FBI couldn't guess your passcode (we'll talk on that later), and only had access to the encrypted content (if they could guess your passcode, then they could just read the phone like you do, everything would be available). In order to decrypt what is on the phone, they would need to defeat the underlying encryption on the phone, which is 256-bit AES. The key size, 256-bit, in part means is that to brute-force guess a key would take a supercomputer (of today's capabilities) 13.75 billion years.

Inherently, then, the brute force guessing of a 256-bit AES key is computationally infeasible and thus impractical; no one is going to live long enough for a successful effort to even matter (6 months from now the information on that iPhone is probably not going to be useful to the FBI, let alone 13+ billion years).

Cracking iPhone Passcodes

Of course, the passcode is just as important. If I were a thief, I'd certainly be trying some easy to guess passcodes, like 0000, 1234, or 4321, etc., with the hope that this is enough to let me break in to a phone in my possession. Sadly, people aren't all that good at choosing passwords or passcodes, and so a great many devices and accounts can be compromised with such a simple attack. But how long would it take our thief to guess a passcode that was chosen by the user carefully, using a brute-force method like trying 0000, then 0001, then 0002, then 0003, and so on until the right passcode was guessed?

The following web article: suggests that it all depends on how many digits your passcode is composed of, as well as the inherent features of the iPhone related to entering your passcode that are intended to thwart users who are trying to break in to your phone. To quote the author:
  • seven-digit passcodes will take up to 9.2 days, and on average 4.6 days, to crack
  • eight-digit passcodes will take up to three months, and on average 46 days, to crack
  • nine-digit passcodes will take up to 2.5 years, and on average 1.2 years, to crack
  • 10-digit passcodes will take up to 25 years, and on average 12.6 years, to crack
  • 11-digit passcodes will take up to 253 years, and on average 127 years, to crack
  • 12-digit passcodes will take up to 2,536 years, and on average 1,268 years, to crack
  • 13-digit passcodes will take up to 25,367 years, and on average 12,683 years, to crack

The author suggests 11 digit passcodes are the best, though I think most people will not find that number of digits to be 
practical (who would want to enter 11 digits to gain access to their phone?)

The design of the iPhone helps somewhat to make small, usable (but carefully chosen) passcodes secure. To quote the author again: 

"One obstacle to testing all possible passcodes is that the iPhone intentionally slows down after you guess wrong a few times. An attacker can try four incorrect passcodes before she’s forced to wait one minute. If she continues to guess wrong, the time delay increases to five minutes, 15 minutes, and finally one hour. There’s even a setting to erase all data on the iPhone after 10 wrong guesses".

As I see it, the above makes even a 4 digit passcode pretty secure for most of us, as it is hard for me to imagine that the run of the mill thief is going to want to spend the time to gain access to my phone unless it is clear to the thief that my phone contains data that is worth the effort.

What The FBI Wants

The FBI wants, essentially, for Apple to provide software that allows them to get around the extra obstacles that Apple has put in place to make it practically impossible to brute force attack the passcode space. They don't want the phone to add delays if wrong guesses are made. With this software, they intend to build what amounts to a machine that can be given a phone, and bang on the screen, trying passcodes one-by-one, until the attack is successful. Of course, this means that with this software, anyone can build such a machine, even the bad guys.

Possible Solution: A Passcode Registry + Search Warrants

Back to the current problem facing the FBI and Apple. The FBI wants Apple and others in the industry to add some sort of backdoor that would allow it to circumvent the security built into iPhones (and other devices). Apple wants none of this, as they know consumers will balk if they think that Apple will bend over backwards for the FBI (or anyone else for that matter). And Apple is also correct that a backdoor would eventually lead to "bad guys" being able to gain access to phones, rendering the security of the phone useless. Silicon Valley is strongly united in opposing such a backdoor, as is any security researcher worth his or her salt.

In the end, I think the problem of securing a phone is not much different than that of securing your home. Any home has at least as much, if not more, sensitive information about the persons living there as does their phones. The government is free to inspect a home as long as they can get a search warrant and have probable cause. As a society, I would presume that we all would be ok with the idea that our phone is subject to similar scrutiny. If a lawyer can prove to a judge that a search of my phone is vital for whatever reason, it's not much different than giving up the keys to my house.

With such a warrant, the FBI could walk up to someone, ask that person to provide the passcode to their phone and the phone itself, and then access its data. But what if the person were dead as in the case of the San Bernardino shooter? How would the FBI obtain the passcode? The only way I see this happening would be for the passcodes to be available to the government. A way to do this would be for Apple to transmit, over an encrypted connection like HTTPS, each passcode as it is changed by a user, and place it in a database that is keyed by the unique identifier associated with the hardware of the phone (each phone has such an ID).  Gaining access to the passcode would be a matter of looking it up in the database, using the unique ID of the phone as a key. With a suitable search warrant, of course.

These passcodes would be stored in an encrypted form in the database, just in case the database were compromised, so the risk would be small if the database fell into the wrong hands, assuming the job is done competently. 

Should the government want to see inside a phone, like the one owned by the San Bernardino shooter, it would go about is as follows:
  1.  come up with probable cause, and get a search warrant
  2.  obtain the phone
  3.  retrieve the passcode from the database
  4.  use the passcode to unlock the phone and gain access to its contents
Again, this would be much like the process the FBI would go through to get a search warrant and search a home, which we've all come to accept. The solution doesn't impact the overall security of the phone, but it does gives the FBI a legal way to get at the contents, if a judge agrees, and eliminates the need for Apple to compromise on the overall security afforded users of the iPhone and iPad. In effect, a backdoor without actually having to implement a backdoor.

Monday, August 25, 2014

How to give virtual machines in Fusion static IP addresses

An interesting post related to OpenStack shows how to give a virtual network adapter in a VM a static IP address assignment with VMware Fusion.

I'm going to copy the content here just in case that page disappears in the future:

Setting fixed IP address for VMware Fusion VM

  1. Open file /Library/Preferences/VMware Fusion/vmnet8/dhcpd.conf
  2. There is a block named “subnet”. It might look like this:
subnet netmask {
  1. You need to pick an IP address outside of that range. For example -
  2. Copy VM MAC address from VM settings->Network->Advanced
  3. Append the following block to file dhcpd.conf (don’t forget to replace VM_HOSTNAME andVM_MAC_ADDRESS with actual values):
        hardware ethernet VM_MAC_ADDRESS;
  1. Now quit all the VmWare Fusion applications and restart vmnet:
$ sudo /Applications/VMware\ --stop
$ sudo /Applications/VMware\ --start
  1. Now start your VM, it should have new fixed IP address

Sunday, January 20, 2013

The easy way to serve static content in Django with apache2

Struggling with how to serve static content (e.g., images referenced from your site template files, like logos) on both the django development server and apache2, without changing code?

A simple approach that does not involve changs to your django project is to add the following to /etc/apache2/apache2.conf:

Alias /static/ /foo/bar/djangoproject/djangoapplication/static/

This would correspond to the following settings in (located in /foo/bar/djangoproject):

STATIC_URL = '/static/'

Doing this allows you to run on the dev server (e.g., python runserver) and when deployed on an apache2 host without any changes to the project.

Backing up an EC2 instance with rsync.

To back up an EC2 instance, you can use rsync.

My strategy is pretty simple. I want to backup to a server in my home. I don't want to expose my server at home via dynamic DNS, so the only option would be to start the backup locally and pull from the EC2 instance.

Fortunately, this is very easy to do. Here are the steps:
  • Figure out what local server you want to do your backups to. In my home, the server is a fairly old (e.g., 2005 model) Mac Mini. To that Mac Mini, I've attached a 2TB drive for holding backups. Let's call that system "A". We'll call the EC2 instance hostname "B".
  • Create a directory on A to hold the backup. I give the name of the directory the same name as the ec2 instance, makes it easy to know which backup is which. I put it on the 2TB drive since I use that drive for backups. Thus, I issue 'mkdir /Volumes/My2TBDrive/B' to create the directory where the backup will be maintained.
  • Copy your private key file (.pem) over to the ~/.ssh directory of machine A, if not already there. This is the key file you generated using the EC2 console before creating the EC2 instance, and it is the same one you use when logging in. Before you copy the keyfile to any .ssh directory, of course, make sure it has a unique name so you don't blow away a key file already there with the same name. Run 'chmod 400 filename' on this file to give it suitable permissions. Let's call the file keyfile.pem.
  • Make sure rsync is installed on both the ec2 instance and machine A.
To do the backup, log onto machine A, issue a command like the following (assuming your login on A is yourusernameA and on B is yourusernameB, you certainly will need to change these values):

$ sudo rsync -avz -e 'ssh -i /Users/yourusernameA/.ssh/keyfile.pem' yourusernameB@B:/  /Volumes/My2TBDrive/B

(Note, since I am using MacOS X, my home directory is under /Users, and mounted drives are found under /Volumes. On Linux, this would be /home/yourusernameA and /mnt/My2TBDrive/B, respectively. Windows users, sorry, I don't discuss Windows in this post).

The 'ssh -i /Users/yourusernameA/.ssh/keyfile.pem' gives you password-less ssh authentication (and associated encryption of the bits on the wire as they are copied from B to A). This is essential if you want to do the backup from a cron job without having to type passwords (and the keyfile is, as best I can tell, required anyway for getting a login to your EC2 instance).

The yourusernameB@B:/ determines what gets backed up. Here, I am backing up from /. The /Volumes/My2TBDrive/B is the location on machine A where the resulting backup will be located.

Making snapshots of EC2 instances

Following is a link that seems to provide solid advice, and is clearly written, but only regarding backups to snapshots:

This method is a bit risky if Amazon has a complete failure, so additionally, would want to use a method such as rsync to do traditional OS backups to an offsite machine. Such as rsync (which I will cover in a subsequent post).

I only use snapshots to record major events in the system lifetime, like initial configuration. Which is good because you don't want a lot of snapshots, anyway. OS backups using rsync are done twice daily from cron.

To restore a failed system, I would create a new instance from a snapshot, then restore from my latest rsync backup.

EC2 Django MySQL phpmyadmin

Here are some notes for getting Django/MySQL/phpmyadmin stack up and running on an EC2 instance. Instructions here are for Django 1.3, and Ubuntu 12.04 LTS.

Django is an excellent framework for building database backed websites, sites are largely built using python, and it takes care of a lot of stuff you'd otherwise have to write by hand (as I did in php years ago). I don't know about you, I'd rather use someone else's user authentication and session management packages: it was ok rolling my own in php (I learned a lot), but I am done with that. Plus, python is without question a much better language than php (all due credit to the php folks). Lots of other advantages as well (rich python libraries, django and otherwise; database tables and forms described as classes).

mysql is an excellent database, of course.

And phpmyadmin is an excellent  tool for configuring and managing MySQL databases.

So, it is natural to want to use them together. Django supports MySQL of course. But django wants to own / on apache, and to get phpmyadmin, you would need to set up virtual hosts. Maybe not a big deal (I did it once before), but I found an easier way. Let django own Apache, fine. Just run phpmyadmin on a different web server (lighttpd) that's listening on port 81. If you search the web a bit, you'll see that it's pretty common to do this. And you can put all your non-Django served content off of lighttpd (docs, etc..), and get some isolation between the two as well.

First, get Django up:
  • Make sure when you create the EC2 instance that you create a security group that enables TCP port 81. This allows you to run two web servers - apache for Django, and lighttpd for phpmyadmin. 
  • Install apache2, django, mysql packages using apt-get. Plenty of resources on the web describe this step. You will be prompted for an admin password when installing MySQL. Remember it, as this is your login to myphpadmin
  • Create an empty django project (plenty of docs on that too).
  • Hack on the settings file to enable MySQL for the django project.
  • Visit and follow instructions.
  • Make sure you can see the default Django page on port 80.
 Next, set up lighttpd and phpmyadmin:
  • Install lighttpd package
  • Install php5 package
    • apt-get install php5-fpm php5
  • Hack on /etc/lighttpd/lighttpd.conf 
  • Install phpmyadmin package
  • system mysql start
  • system lighttpd force-restart
  • Visit http://server:81/phpmymyadmin - it should be running
  • Login using the user and password configured when you installed the MySQL package.