Security and Trust of Public Key Cryptography for HIP and HIP Multicast

Security and Trust of Public Key Cryptography for HIP and HIP Multicast

Amir K.C, Harri Forsgren, Kaj Grahn, Timo Karvi, Göran Pulkkis
DOI: 10.4018/jdtis.2011070102
OnDemand:
(Individual Articles)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Host Identity Protocol (HIP) gives cryptographically verifiable identities to hosts. These identities are based on public key cryptography and consist of public and private keys. Public keys can be stored, together with corresponding IP addresses, in DNS servers. When entities are negotiating on a HIP connection, messages are signed with private keys and verified with public keys. Even if this system is quite secure, there is some vulnerability concerning the authenticity of public keys. The authors examine some possibilities to derive trust in public parameters. These are DNSSEC and public key certificates (PKI). Especially, the authors examine how to implement certificate handling and what is the time complexity of using and verifying certificates in the HIP Base Exchange. It turned out that certificates delayed the HIP Base Exchange only some milliseconds compared to the case where certificates are not used. In the latter part of our article the authors analyze four proposed HIP multicast models and how they could use certificates. There are differences in the models how many times the Base Exchange is performed and to what extent existing HIP specification standards must be modified.
Article Preview
Top

Survey Of Hip And Its Security

In this section we give an overview of HIP and its security mechanisms. For more detailed surveys, see (Gurtov, 2008; Nikander et al., 2010).

Cryptographic Name Space and the Base Exchange

HIP adds a new name space to the TCP/IP protocol stack. Network hosts are identified HIs, which are public cryptographic keys. Therefore, peers authenticate directly by their HIs. HIP is backwards compatible, i.e. no changes to the network infrastructure or to applications are needed. In order to bind other names to HIs, Host Identity Tags (HITs) and mechanisms like DNSSEC, SPKI certificates, and X.509 certificates are available.

If an entity A wants to start a HIP connection with B, A first makes a DNS query to get B’s IP address and HI. In this query, A uses human-friendly host names. It is essential that A can trust the DNS response. If the response data is incorrect, then A could communicate with a malicious entity without noticing it.

There can be only one HIP SA between a pair of HITs. Multiple SAs between two hosts require several HITs per host. Therefore, a host may have several RSA or DSA public/private key pairs.

A HIP connection is negotiated by a Base Exchange protocol, see Figure 1. An initiator I starts the negotiation with a responder R. Messages R1, I2, R2 are signed (sig). R1 and I2 contain Diffie-Hellman parameters (DH(r), DH(i)), a puzzle (in R1), its solution (in I2), and a puzzle difficulty parameter K. R1 and I2 may contain certificates. Normally the signature in R1 can be calculated beforehand, because the signature does not contain HIT(i) or the checksum if a puzzle is used. After receiving R1, I calculates the Diffie-Hellman secret. R calculates the same secret after receiving I2. This secret is used in the hmac values in I2 and R2. The hmac value is checked before the signature is checked. The CERT parameter is optional. It is contained in the variable size part of the HIP packet. The maximum HIP packet length is 2040 bytes and the maximum parameter field length is 2008 bytes.

Figure 1.

HIP base exchange

jdtis.2011070102.f01

The standard also allows an opportunistic mode in which I starts Base Exchange without HIT(r) in I1 (it is set to zero). This mode creates security vulnerabilities and should be avoided in unsecure environments.

Complete Article List

Search this Journal:
Reset
Volume 2: 3 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing