curious bytes

The State of NFC in Android

NFC is near

Near Field Communication technology (NFC) is not exactly new, but it's been getting a lot of attention lately. With the exception of Japan where Sony's FeliCa cards are ubiquitous, used for anything from public transportation and mobile payments to gym membership cards, most deployments have been limited by service sector or location. With the wider deployment of MasterCard's PayPass and similar services, it's finally catching on in the US. And Google has taken notice: Android 2.3 (Gingerbread, released in Nov 2010) had initial read-only NFC support, with later versions (2.3.3, 2.3.4) introducing write access to NFC tags as well as peer-to-peer communication. Google Wallet, announced yesterday, builds upon this to introduce mobile payments, loyalty cards, coupons and maybe more in the future. So just how good is NFC support and Android and can you build your own service around it? 

Customizing AWS Elastic Beanstalk

Introducing Elastic Beanstalk

One of the newest additions to the Amazon Web Services (AWS) family is Elastic Beanstalk. While using AWS gives you the freedom to install and run pretty much anything on any platform, and mix and match servers as you wish, sometimes you just need to quickly deploy a web application and be done with it. Enter Platform as a Service (PaaS). Different full-stack solutions have been available for a while from Google (App Engine, Java and Python), Heroku (Ruby), and Microsoft (Azure, .NET). Amazon is a bit late to the party, but their new Elastic Beanstalk service lets you easily deploy a Java web application (WAR) without the hassle of setting up Tomcat, Apache, mod_jk and what not. According to Amazon, additional stack are to be added later. 

DNSSEC Operation Tools - BIND 9.7

In the last article of our DNSSEC automation tools review we will discuss the automation features of the newest version of the BIND nameserver -- 9.7.

Introduction and Background

The BIND nameserver hardly needs an introduction, so we'll skip on that. We'll briefly introduce the DNSSEC-related new features of BIND 9.7 instead. BIND has supported DNSSEC since its 9.3 days (2005), but only basic tools (dnssec-keygen and dnssec-signzone) were available as part of BIND and that lead to the creation of projects such as ZKT. To remedy the situation, BIND 9.7 was themed 'DNSSEC for Humans' and a number of new features that simplify DNSSEC configuration and maintenance were added. The official ISC New Features in BIND 9.7 article introduces all of those. Here we present just the features most relevant to our discussion:

• new DNSSEC key metadata and lifecycle maintenance
• new utility - dnssec-settime, and changes to dnssec-keygen/signzone
• smart signing
• automatic zone signing
• improved PKCS#11 support for using HSMs for key storage and signing (we discussed HSM support in a previous article)

DNSSEC Operation Tools - OpenDNSSEC

Continuing our review of DNSSEC operation automation tools, we will now discuss one of the more ambitious projects -- OpenDNSSEC.

Introduction and Background

OpenDNSSEC aims to provide a solution that relieves administrators from the complexities of DNSSEC and makes integrating an HSM a non-issue. Unlike ZKT, which is mostly a one man project, OpenDNSSEC is an international co-operation effort. Some of the participants are key players in the DNS and DNSSEC world: The Internet Infrastructure Foundation, Kirei (part of the Root DNSSEC design team), NLnet Labs (developers of the NSD name server and the Unbound caching resolver); as well as leading European DNS registrars.

OpenDNSSEC is a fairly young project: the first public release was done in August 2009, and version 1.0 was released in February 2010. Unlike most young open source projects, OpenDNSSEC comes with a clearly stated release plan, has extensive documentation and even has its own marketing material.

All in all, it looks like a very promising project, so let's give it a try.

DNSSEC Operation Tools - ZKT

In our last article we saw why maintaining a DNSSEC-enabled domain requires automation and introduced some DNSSEC operation automation tools. We will now have a detailed look at the first of those tools -- the DNSSEC Zone Key Tool, also known as ZKT.

Introduction and Background

As mentioned in the DNSSEC introduction article, the first version of BIND to support DNSSEC was 9.3, released in 2005. It had the basic tools to implement DNSSEC -- key generation and zone signing commands, but there were quite a few steps required to sign a zone and all command parameters needed to be specified manually, since there was no support for automatic key selection. The first public version of ZKT, 0.5, was released at about the same time as BIND 9.3 -- April 2005 with the intention to make DNSSEC-enabled zone maintenance a bit easier.

DNSSEC Operation Tools

In this article we will review some of the operational complexities of DNSSEC, see how operations can be automated and introduce some tools that aim to make life easier for DNSSEC administrators. Hopefully, you've read the other articles of the series and you are already familiar with the basics of DNSSEC. If not, now might be a good time to review the first article.

DNSSEC is Here Now!

So how is DNSSEC deployment progressing? The root zone has now been signed and the root zone trust anchor is available. If you are interested how the whole operation is organized, the root zone KSK operation practices are also available. While the root key is operated by ICANN and Verisign, 21 trusted community representatives have been selected to participate in the root key generation, backup and key signing process. 7 of those have been given smart cards containing a part of the key used to encrypt backup copies of the root ZSK. While they have been called 'key masters' and 'holders of the keys to the Internet' by popular technology websites, they are not exactly members of a secret society: their names have been publicly announced. By the way, the technical (and somewhat boring) term for 'Internet key master' is 'Recovery Key Share Holder' (details here).

The Need for Tools

So the main excuse for not deploying DNSSEC to your own servers is no more. Let's get started.

Performance and Security Implications of Using an HSM for DNSSEC

In the previous article of the series, we introduced HSMs and configured our BIND installation to use an nCipher netHSM for DNSSEC key generation and zone signing. We will now look at the performance implications of using an HSM. All measurements were done on a Linux machine with a quad-core Intel Core 2 2.83GHz CPU and 2GB of memory. The HSM we used is an nCipher netHSM 2000 (the '2000' is the number of advertised 1024-bit RSA key operations per second); the BIND version is 9.7.

Key Generation Performance

For our first test, we compared 1024-bit RSA key generation time when using software (BIND + vanilla OpenSSL) and an HSM (BIND + OpenSSL with the PKCS#11 engine patch). As you can see from Graph 1, generating keys in software is 10 to 100 times faster than generating them with an HSM. As discussed in the previous article, HSMs are equipped with cryptographically secure random number generators that provide higher quality randomness (more entropy) for key generation. The price to pay for this is, however, speed. For high-value keys, such as KSKs for large domains, key security is usually much more important than generation speed and this is a worthy trade-off. Taking into account that DNSSEC keys are generated offline, and possibly well ahead of their activation date, the key generation speed the HSM provides should be more than sufficient.

Using an HSM for DNSSEC with BIND

In the previous article we introduced DNSSEC and showed how to implement an authoritative DNSSEC-enabled name server using BIND. We will now look at how to use an HSM with BIND to store signing keys and sign zones.

Why Use an HSM?

An HSM (Hardware Security Module) provides two main services: hardware security and cryptographic acceleration. While there are many ways to protect cryptographic keys from unauthorized access in a software system, once you have physical access to it, complete protection is impossible. At some point, the unencrypted keys will reside in memory and all that is needed to gain access is taking a memory dump and analyzing it. This is not an easy task though, and such software only protection is adequate for general use. However, for high-value applications, such as certificate authorities (CA), financial transactions and high-value domain keys, such a limited level of security is insufficient. HSMs generate and use keys inside a physically secure module, guaranteeing that plain text keys are never on the host computer (either in memory or on disk).

A Short Introduction to DNSSEC with BIND

In this series of articles we will introduce DNSSEC, see how to actually implement it using BIND, and explore some performance and security issues regarding DNSSEC keys and zone signing.  Let's start with a little background.

What is DNSSEC?

So what is DNSSEC and why do we need it? As the name implies, the main goal of DNSSEC is to secure DNS. The DNS protocol was designed to be scalable and lightweight, but security was not taken into consideration (it was not really a concern at the time). A number of security flaws in DNS were discovered in the late 1990s and it became apparent that a more secure domain name system is needed. Since one of the main problems is that DNS replies can be easily forged, DNSSEC adds digital signatures to DNS replies in order to protect DNS clients (resolvers) from forged data. By verifying the digital signature of a DNS reply, resolvers can check if the information is identical to the one on the authoritative DNS server. DNSSEC however does not provide confidentiality: responses are authenticated but not encrypted.

For more details about how DNSSEC addresses DNS security threats an how it actually works see:

• RFC 3833 A Threat Analysis of the Domain Name System
• RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)

Integration Testing Persistence Logic with DbUnit in Spring

The first part concluded with the idea that it is easiest to use minimal fixtures, loaded for every test when testing persistence logic. Now we'll see how to actually implement the loading/unloading of those fixtures using DbUnit and Spring.

Spring 2.5 introduced a new integration testing framework with several nice features like transaction management and dependency injection of test fixtures, but offers nothing like Seam's DBUnitSeamTest which automatically loads/unloads our fixture data for us.

Building on Spring's integration testing framework and taking a few hints from Seam, we can create a base class for all our integration tests. It will load our fixture from a DbUnit dataset file before every test and take care of cleaning up afterwards, so we don't have to deal with interacting tests. Transactions are managed by Spring's test framework: by default a new transaction is started for each test, and rolled back after the test finishes. You can override this behaviour by annotating your test methods with @Rollback(false).