Monday, October 24, 2011

Android Command Line Dev with VI

Notes on developing Android apps from *NIX command line.

If you are a Vi user, then building your Android application from the command line can save you time.  Here are my notes on setting up Vim w/ tags and code completion for Android development.  I've also included the relevant Ant commands for building Android apps from the command line.  The example includes the commands for building and installing an Android app that links to a dependent java library which resides outside of the project source tree (in this case, the lvl lib), along with a C shared library that resides in the local jni/ directory.

Useful Vim Plugins for Android Development
Setting up Vim JDE (vjde) requires a few configuration changes in order to work well with Android projects.  First, you will need to download vjde.tgz version 2.6.18 from

Place vjde.tgz in $HOME/.vim and tar -zxvf vjde.tgz from within $HOME/.vim.  Change the permissions on $HOME/.vim/plugin/vjde/readtags as follows:
$ chmod +x $HOME/.vim/plugin/vjde/readtags
Fire up an empty editor:  $ vim and enter the following in command mode:
:helptags $HOME/.vim/doc
:h vjde 
will then pull up the help page.

That should take care of setting up vjde.  Now cd to your Android project dir.  Open a blank editor and input the following in command mode:
:Vjdeas .myproject.prj
:let g:vjde_lib_path='/<path_to_android_sdk_top_level_dir>/platforms/ \
Next, Open up a source file in your project and type :Vjdeload .myproject.prj in command mode (or script and/or add to .vimrc).  You can then use <ctrl-x><ctrl-u> for code completion. For example: import android.<ctrl-x><ctrl-u> and you will get a nice little dialog box for browsing the matching frameworks.

Next, run ctags over your java and native sources as follows:
$ ctags -R src gen jni
Once NERD tree and Taglist are placed in ~/.vim/plugin/, the following lines in your .vimrc will allow you to use <ctrl-n> and <ctrl-m> to toggle the file explorer and visual tag list.
nmap <silent> <c-n> :NERDTreeToggle<CR>
nnoremap <silent> <c-m> :TlistToggle<CR>
Also, if you need a status line:
set statusline=\ %{HasPaste()}%F%m%r%h\ %w\ \ CWD:\ %r%{CurDir()}%h\ \ \ Line:\ %l/%L:%c
function! CurDir()
let curdir = substitute(getcwd(), '/Users/myhomedir/', "~/", "g")
return curdir

function! HasPaste()
if &paste
return 'PASTE MODE  '
return "
Vim should be good to go at this point. cd back to $HOME/src/myproject.  This particular example accounts for a dependent Java library (the lvl) that resides outside of the project source tree, a shared library (which consists of a few C files natively compiled), and plain java source files in the appropriate src/com/ package subdir.

From within your top level project dir (assuming that you came from Eclipse, otherwise, you can use android create ...),
$ android update project --name myproject --target <desired_sdk_target> \
  --path $HOME/src/myproject
$ android update project --target <desired_sdk_target> --path $HOME/src/myproject \
  --library ../lvl_lib_dir
Make sure to check to ensure that the android.library.reference.1 variable now contains the relative pathname of the lvl lib directory.

Assuming that jni/ and jni/ are appropriately setup for your shared library, run ndk-build from the top level project directory.
ant debug should now handle the build and debug version of the application package file.

Start up an Emulator and then install your app with a
db -r install bin/myproject-debug.apk or use ant install.
Next, open the Dev tools application in the emulator and configure the following: set wait for debugger and select your application for debugging.

Next, run ddms & and check the debug port. It should be 8700.
Subsequently, start your activity with
adb shell 'am start -n com.mycohname.myproject/.BaseActivityName'
And finally, connect via jdb from the shell with
$ jdb -sourcepath $HOME/src/myproject -attach localhost:8700 
and start your debugging.

Tuesday, September 6, 2011

Radius and 802.1X

Notes for FreeRadius configuration on OS X

If you are like me and you have various WiFi enabled devices at your home, then managing long pre-shared access keys for your network is challenging. If you change the key, then all of the devices can no longer connect. Access rules on your router might allow you to whitelist specific hardware MAC addresses and there might be a firewall application built into your home router. Easier device management and increased wireless security can be easily accomplished with an inexpensive computer running Linux or FreeBSD computer and a Netgear WNR3500U/L router. You can image the router via guides available on Imaging the router with a Linux distribution will allow you to catapult its features into the enterprise space. For the purposes of what I am doing here, I needed Radius and WPA2 Enterprise support on the router.

My goal for this setup was to setup a root Certificate Authority, issue individual client device certificates, and then sign those certificates with my CA. A FreeRadius server is running on a spare Mac OS X 10.6 Imac. I have a WNR3500L/U running dd-wrt, w/ Radius and WPA2 Enterprise support. I will issue and sign certificates for a Nexus S 4G, a couple of MacBooks, and an iPad. FreeRadius is highly customizable and offers different methods of authentication. The WNR3500L/U is connected to the Radius authentication server using a Pre shared key over port 1812/1813. Ipfw works well to lock down source and destination addresses over port 1812. dd-wrt supports iptables. note: I am running the FreeRadius server on OS X 10.6 Desktop (not server). FreeRadius is configured for EAP-TLS authentication and the dd-wrt router (actually I'm running dd-wrt on two WNR3500L/Us chained together) is configured for WPA2 Enterprise w/ AES/TKIP. OpenSSL key and cert configuration details are below. I've left off the config for radiusd.conf. I suggest running FreeRadius server with the default config first and then locking it down to just the protocols you want/need. I also suggest setting your OpenSSL key gen preferences in openssl.cnf prior to running these commands; namely, turn up the key strength, and lock it down. Also, store your passphrases in a safe place after generating them (i.e. openssl rand -base 64 37 | shasum-5.12 -a 512 | cut -c1-32). Last of all, chmod -R 0400 your private keys and config files, and chown -R freeradius:freeradius appropriately. I've left off the output of the commands below for clarity. The common name must be unique between client certificates. Last, the iPhone configuration utility is needed for creating configuration profiles on OS X 10.7+ and iPad/iPhones. Here are the steps.

1. Generate a new self-signed root CA, write the encrypted private key to CA/private/cakey.pem, and then write the Base-64,ASN.1-encoded, self-signed certificate to CA/cacert.pem. This certificate will be used for signing client and server certificates.
# openssl req -new -x509 -extensions v3_ca -keyout CA/priv/cakey.pem \
  -out CA/cacert.pem -days 730 -config openssl.cnf 
# openssl x509 -in cacert.pem -noout -text 
# openssl x509 -in cacert.pem -noout -dates
# openssl x509 -in cacert.pem -noout -purpose
# openssl x509 -in cacert.pem -noout -issuer 
# openssl rsa -noout -modulus -in CA/priv/cakey.pem | openssl sha1
# openssl x509 -noout -modulus -in CA/cacert.pem | openssl sha1
Check the modulus and public exponent in the private key and certificate to make sure they match.
# openssl rsa -noout -modulus -in CA/priv/cakey.pem | openssl sha1
# openssl x509 -noout -modulus -in CA/cacert.pem | openssl sha1
2. Export the root CA signing certificate to ASN.1, DER encoded format so that clients can import it.
# openssl x509 -in CA/cacert.pem -outform DER -out clientCerts/myRootCA.der
2a. Convert the DER encoded CA back to pem format and place in a .crt file so that Android can read it. (This is an extra, un-needed step as cacert.pem can be copied and renamed to .crt). (Android does not understand pem files so write the DER encoded certificate to PEM format in a file with extension .crt).
# openssl x509 -inform der -in clientCerts/myRootCA.der -out clientCerts/myRootCA.crt
3. Generate radius server certificate (i.e. signing request) and private key in unencrypted format.
# openssl req -new -nodes -keyout tempCerts/radius_key.pem \
  -out tempCerts/radius_req.pem -days 730 -config openssl.cnf
4. Sign the radius server certificate. note: if you have any Microsoft clients, you'll need to create an xpextensions file and then add '-extensions xpserver_ext -extfile ./xpextensions' to the following command.
# openssl ca -out tempCerts/radius_cert.pem -infiles tempCerts/radius_req.pem \
  -config openssl.cnf
5. Install the root CA signing certificate, Radius server private key, and Radius server signed certificate.
# cp tempCerts/radius_cert.pem /etc/radwl/certs/server/
# cp tempCerts/radius_key.pem /etc/radwl/certs/server/
# cp CA/cacert.pem /etc/radwl/certs/server/
6. Create the client certificate (i.e. signing request) and private key. note: match the output file names with the client identity or common name.
# openssl req -new -keyout tempCerts/myandroid_key.pem \
  -out tempCerts/myandroid_req.pem -days 730 -config openssl.cnf
7. Sign the client certificate.
# openssl ca -out tempCerts/myandroid_cert.pem -infiles tempCerts/myandroid_req.pem \
  -config openssl.cnf
8. Export the signed client certificate and private key to pkcs #12 format
# openssl pkcs12 -export -in tempCerts/myandroid_cert.pem -inkey \
  tempCerts/myandroid_key.pem -out clientCerts/myandroid_cert.p12 -clcerts
9. Install the signed client certs on the Radius server.
# cp tempCerts/*_cert.pem /etc/radwl/certs/clients
10. Copy the client pkcs#12 certificate to appropriate device.
# cp clientCerts/myandroid_cert.p12 DEVICE
11. Copy the CA signing certificate to the same device.
# cp clientCerts/myRootCA.crt DEVICE
12. on OS X, use the following commands to add the freeradius user to the freeradius group. Also run chsh freeradius and set the shell to /sbin/nologin
# dscl . append /Groups/freeradius GroupMembership freeradius

Tuesday, August 16, 2011

OpenSSH Security - Client Configuration

OpenSSH provides a suite of tools for encrypting traffic between endpoints, port forwarding, IP tunneling, and authentication. Part I of this guide will outline the client side OpenSSH configuration. The OpenSSH client is running on OS X Lion. The built in firewall, ipfw, is enabled on the client to restrict outbound and inbound traffic. Part II (currently on hold) of this guide will cover the configuration of OpenSSH on the server along with the available options and alternatives for authentication, authorization, and traffic encryption. The configuration will force AES 256 in Counter Mode and will restrict the available Message Authentication Algorithms that may be used between endpoints. Most of the options in the ssh configuration file on the server will be disabled, public key authentication will be used, password authentication will be disabled, and the ssh daemon will bind to a high number port. Multiple SSH sessions will use the same connection via the ControlMaster and ControlPath client configuration directive. Also, a server certificate will be generated and used to sign user public keys. The CA signed user public keys constitute a user certificate which the server will in turn use for client authentication. PF will be used on the server for stateful packet filtering, connection blocking, and connection throttling. The below configuration will also detail

First and foremost, the client has ipfw enabled and the firewall ruleset is configured in /etc/ipfw.conf. ipfw has been configured to block all inbound traffic and block all outbound traffic except for the ports and IP addresses that are necessary for connecting to the OpenSSH server. The server is running FreeBSD 8.2.

FreeBSD 8.2 - sshd on a.b.c.d:21465 pf |  <--------Internet---------->  | ipfw  OS X Lion - ssh client
To start with, you will need to install coreutils and apg on the client. coreutils and apg can be obtained from Mac ports and can be installed as follows:

client: $ sudo port install coreutils 
client: $ sudo port install apg 

Before generating your public/private keypair, You will need to generate a strong passphrase for your private key. It is important to store this passphrase in a secure location, not on your computer.

client: $ openssl rand -base64 1000 | shasum-5.12 -a 512 | apg -M SNCL -a 1 -m 20 -x 20

Depending on your version of OpenSSH (should be using latest stable for your OS), ECDSA may be used in addition to DSA and RSA. Certificates may also be used for user and host authentication. See the ssh-keygen man page for details.
You can generate your keypair using the following command. When prompted for the passphrase, use the output from the above command.

client: $ ssh-keygen -b 4096 -t rsa -C"$(id -un)@$hostname)-$(gdate --rfc-3339=date)"

Here is an example of how to use ssh-keygen to generate a public/private keypair using the Eliptic Curve Digital Signature Algorithm. Both the client and server must be running a version of OpenSSH >= 5.7.

client: $ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$hostname)-$(gdate --rfc-3339=date)"

Now, we need to push the public key to the server and place it in the authorized_keys file of the user that we are going to log in as over ssh.
The ssh-copy-id command can be used to automate this process. On the OS X client, the ssh-copy-id command does not come preinstalled with SSH. The ssh-copy-id command can be obtained from;content-type=text%2Fplain. After downloading the script, change its permissions and place it in your path.
At this point, you should already have a server that is running OpenSSH on port 22 with the default configuration. Thus, you can transfer your public key with the following command:

client: $ ssh-copy-id -i ~/.ssh/ bryan@a.b.c.d \

It is time to setup connection sharing. Create the following file if it does not currently exist.

client: $ ls -l ~/.ssh/config -rw------- 1 bryan scclp 104 Aug 13 10:55 config

The file should contain these lines.

ServerAliveInterval 60 Host a.b.c.d ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h:%p

The goal is to only allow connections to the server in AES 256 Counter mode, with umac-64 or hmac-ripemd160 MACs, and compression, on a non-standard SSH port from a designated IP range using public key authentication. Connections will also be throttled and SSHGuard along with a few custom PF rules on the server will be used to block and log attackers. The commands that the client will use to connect to the server will look like this:client: 

$ alias sshconnect="ssh -l bryan a.b.c.d -p 21465 -C -c aes256-ctr -m,hmac-ripemd160 client: 
$ alias sshtunnel="ssh -v -ND 8090 bryan@a.b.c.d -p 21465 -C -c aes256-ctr -m,hmac-ripemd160 client:
$ alias sshmonitor="yes | pv | ssh -l bryan a.b.c.d -p 21465 -C -c aes256-ctr -m,hmac-ripemd160 \"cat > /dev/null\"" client: 
$ alias sshportforward="ssh -f bryan@a.b.c.d -p 21465 -C -c aes256-ctr -m,hmac-ripemd160 -L 15478:localhost:15479 -N" client: 
$ alias sshportforward2="ssh -f bryan@a.b.c.d -p 21465 -C -c aes256-ctr -m,hmac-ripemd160 -L 17293:localhost:17294 -N"

Alternatively, Ciphers, MACs, and compression can be specified in the user config file as follows:

ServerAliveInterval 60 
    ControlMaster auto 
    ControlPath ~/.ssh/sockets/%r@%h:%p 
    Port 21465 
    User bryan 
    Ciphers aes256-ctr 
    Compression yes 
    StrictHostKeyChecking yes

User and Host certificates provide a more convenient method of authentication for multiple clients (users) and servers (hosts). Certificate revocation can also provide an easier method of quickly invalidating user access.A certificate authority key pair is first generated as follows. The ca is then placed in the /etc/ssh directory on the host.

ca $ ssh-keygen -t ecdsa -b 521 -f user_ca server $ sudo mv user_ca* /etc/ssh/

On the client, generate a public/private key pair and then copy the public key to the server so that it can be signed with the ca. Make sure to set the validity period of the certificate. Alternatively, a host key may be signed with a ca key that is stored in a PKCS11 token. OpenSSH supports ca keys stored PCKS11 tokens. Check your version of SSH and see ssh-keygen for more information.client 

client $ ssh-keygen -t ends -b 521 -f ~/.ssh/id_ecdsa 
client $ scp .ssh/ bryan@server-ca:~/user_public_keys 
server-ca $ ssh-keygen -s /etc/ssh/user_ca \ 
      -O source-address=clientip 
      -O permit-pty 
      -O no-port-forwarding       
      -O no-user-rc 
      -O no-x11-forwarding \ -V -1d:+52w1d -z 6739301351 -I "bryan"       -n bryan,clienthostname
id "bryan" serial 6739301351 for bryan,clienthostname valid from 2011-08-18T15:05:24 to 2012-08-17T15:05:24 

Copy the signed user cert back to the client.

client $ scp bryan@server:~/user_public_keys/ ~/.ssh/ 

Setup TrustedUserCAKeys and AuthorizedPrincipalsFile files. Subsequently, set appropriate options in /etc/ssh/sshd_config on the server.

server-ca $ sudo cat /etc/ssh/ > /etc/ssh/trusted_user_ca_keys 

Modify /etc/ssh/authorized_principals to include the following lines.bryan from="clientip" bryan
Modify /etc/ssh/sshd_config on the server to include the following lines

TrustedUserCAKeys /etc/ssh/trusted_user_ca_keys 
AuthorizedPrincipalsFile /etc/ssh/authorized_principals 

Now, restart sshd on the server and add an appropriate host configuration for certificate authentication to ~/.ssh/config on the client.

Last of all, if you want to setup a host certificate, you will need to use the -h option with ssh-keygen when signing a host key.

In the second part of this guide (currently on hold), I will cover how to lock down SSH on the server. I will also cover port knocking, Single Packet Authorization (SPA), and other options for authentication including Kerberos 5, PAM, and two/three factor authentication using the Google Authenticator project.

It is important to always keep OpenSSH updated with the latest, stable version that has been released for your operating system.






Thursday, March 3, 2011

Device Encryption in Android 3.0

Transparent encryption of block devices in Android 3.0

The Motorola Xoom and a number of new tablets on the market run Android 3.0, Honeycomb. Android 3.0 is built on the 2.6.36 Linux kernel. Most, if not all, of the Android tablets that are coming to market feature an Invidia Tegra 2 processor. The 2.6.36 Linux kernel on these Android 3.0 Tegra 2 tablets introduces transparent, whole disk encryption to the everyday user. Transparent, whole disk encryption is provided by the dm-crypt device-mapper target in the Linux kernel. This target provides a virtual layer on top of an existing block device and uses the crypto APIs in the Linux kernel for encryption and decryption of the underlying block devices.

Whether you are typing commands via a shell over a serial port or you are using the e-mail application to check your e-mail, reads and writes to the file system are performed in the same manner with no changes to the upper level applications.

After pressing the power button on the back of the Xoom tablet, the tablet boots and the user is presented with the desktop environment; from which he or she may choose to play a game, check e-mail, or read an e-book.By tapping on settings and then Location & security, one can choose to "Encrypt tablet" from this screen. Upon doing so, the encryption process takes about 1.0 hours and the user is presented with a few basic screens.

After the encryption process is finished, the tablet is powered down. Upon rebooting the tablet, the user is prompted to input a pin code which is used to unlock the device. Upon typing the correct pin code, the tablet powers up as normal and the user can proceed with performing his or her standard activities - checking e-mail, reading e-books, etc.

The Linux 2.6.36 kernel supports what is called the device mapper framework. The Device Mapper Framework allows you to map virtual layers on top of block devices for doing things like striping and mirroring. device-mapper also provides a convenient target called dm-crypt. dm-crypt is a device-mapper crypto target. the dm-crypt target provides transparent encryption of block devices.

Before the encryption operation above, here is the output of the mount command which shows the device name and mount point. This is an important partition because it is where the user's data is stored. Consequently, this is the partition that will get encrypted.

/dev/block/platform/sdhci-tegra.3/by-name/userdata on /data type ext4 (rw,nosuid,nodev,noatime,barrier=1,data=ordered)

A few mount options to take note of: noatime, barriers and data=ordered

...And after the encryption operation

/dev/block/dm-0 /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
dmsetup will give us more information. As you can see from the below command, a dm-crypto device mapper target called crypt, has been setup in the kernel. The dm-crypt target provides transparent encryption and decryption of data on the block device using the crypto APIs in the Linux kernel.

# dmsetup targets

crypt v1.7.0
striped v1.3.0
linear v1.1.0
error v1.0.1

# dmsetup status

datadev: 0 61326304 crypt

Albeit the details surrounding key storage (see kernel source), supported ciphers (cat /proc/crypto), and hardware acceleration (see kernel source), here are some rudimentary performance tests that I ran before and after encrypting /data. For the interested reader, there are some kernel level details related to the Tegra 2 processor which one can discover by going through the source code for the Linux 2.6.36 Tegra 2 branch.

The initial results of the the basic tests look good. There is a dedicated kernel thread for handling IO. The read latency appears to be related to the kernel IO thread since reads on flash based storage devices can usually be performed in near constant time.

Unencrypted (2 GB Write - 104857 2k blocks)/data/local/tmp

# time dd if=/dev/zero of=ofile bs=2k count=1048572

1048572+0 records in
1048572+0 records out
2147475456 bytes (2.0GB) copied, 255.912521 seconds, 8.0MB/s
real 4m 17.25s
user 0m 0.73s
sys 0m 24.55s

Unencrypted (2 GB Read - 104857 2k blocks)/data/local/tmp 

# time dd of=/dev/null if=ofile bs=2k count=1048572

1048572+0 records in
1048572+0 records out
2147475456 bytes (2.0GB) copied, 101.749864 seconds, 20.1MB/s
real 1m 41.79s
user 0m 1.15s
sys 0m 17.62s

Encrypted (2 GB Write - 104857 2k blocks)/data/local/tmp

# time dd if=/dev/zero of=ofile bs=2k count=1048572

1048572+0 records in
1048572+0 records out
2147475456 bytes (2.0GB) copied, 260.219584 seconds, 7.9MB/s
real 4m 26.94s
user 0m 0.64s
sys 0m 24.12s

Encrypted (2 GB Read - 104857 2k blocks)/data/local/tmp 

# time dd of=/dev/null if=ofile bs=2k count=1048572

1048572+0 records in
1048572+0 records out
2147475456 bytes (2.0GB) copied, 124.291204 seconds, 16.5MB/s
real 2m 4.31s
user 0m 0.47s
sys 0m 7.74s

As a side note: After performing the encryption operation, and subsequently building a Tegra 2 kernel for experimentation, I noticed that when I booted into the bootloader and ran fastboot boot myKernelBootImg, I was prompted with an error message which stated that the "fastboot boot" command is not allowed on consumer devices

In conclusion, the devicer-mapper target, dm-crypt, provides transparent, whole-disk encryption for Android 3.0 based tablet devices. It is something worthy of heavy consideration.

* get the block size for a device blockdev --getbsz /dev/block/dm-0

Sunday, February 27, 2011


I picked up a Motorola Xoom tablet on February 24th, the day of its release. To start with, the Xoom is equipped with a Dual-Core ARM Cortex A9 processor called the Nvidia Tegra 2. The Xoom runs Android 3.0, Honeycomb. There are no third party UI replacements or additions. The Xoom runs pure Android 3.0 and it is very fast.

 One of the nice things that you can do is customize the keyboard. For a 10 inch tablet, it is convenient to be able to type with your left and right thumbs and Thumb Keyboard is available on the Android Marketplace just for this.

 Thumb Keyboard greatly speeds up typing on the Xoom

 Next, let's build a statically linked Busybox binary so that you can do something useful with the device.
# wget
# wget
# gpg --check-sigs vda.linux
# gpg --verify busybox-1.18.3.tar.bz2.sign
# sha1sum busybox-1.18.3.tar.bz2
# md5sum busybox-1.18.3.tar.bz2
# bzip2 -cd busybox-1.18.3.tar.bz2 | tar xf -
# cd busybox-1.18.3
# make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- defconfig
# make CFLAGS=--static LDFLAGS=--static ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
# adb remount
# adb push busybox /system/xbin/busybox
# adb shell chmod 0755 /system/xbin/busybox
# adb shell
# cd /system/xbin
# ./busybox --install -s /system/xbin
# cd /mnt/sdcard
# echo "export PATH="export PATH=/system/xbin:/sbin:/vendor/bin:/system/sbin:\
  /system/bin" > profile
# echo "ENV=/mnt/sdcard/profile /system/xbin/ash" > /system/bin/alsh
# chmod 0755 /system/bin/alsh
# alsh
# uname -ia
# Linux localhost #1 SMP PREEMPT Mon Feb 7 15:24:33 PST 2011
  armv7l GNU/Linux
Now, whenever you adb into your device, you can just run alsh to drop into the ash shell.
 "Now I want an Android device so that I can Androidy it" - KLK