libFNR - A reference implementation for FNR encryption scheme.

FNR is a block cipher to encrypt small domain
objects (< 128 bits) like IPv4 addresses, MAC addreses,
Serial numbers, Account ids, Credit Card numbers etc.
while preserving their lengths (and formats if needed)

FNR is accepted for  SPACE-2014 conference and published in LNCS
and slides here 

IMPORTANT:  This is an experimental cipher 

FNR represents "Flexible Naor and Reingold"

Motivation

Cloudification of application stacks, legacy systems, databases etc. has many benefits but ensuring privacy of sensitive fields might become messier and challenging. Such privacy preserving efforts involves identification of sensitive fields in the system and re-engineering such data fields in order to encrypt them.

For example, a data field might be well-defined for accommodating IPv4 address of size 32 bits with number of validations throughout the application stack (and/or database) to ensure the input data is in fact IPv4 address. In order to preserve the privacy of this field using traditional AES-128 scheme it has to be re-engineered to accommodate 128 bits of memory instead of 32 bits. Also any validations that identifies the type of the data (dotted notation of IPv4 address) needs to be removed in order to accommodate a random cipher string of encrypted IPv4 address.

While the length expansion of the field needs more storage (and/or bandwidth) the removal of validations might open up serious security vulnerabilities in the form of injection attacks. The same issue is applicable while ensuring privacy of any sensitive fields like MAC addresses, Email addresses, Usernames, Account numbers, Serial Numbers, SSN, Credit Card numbers etc.

FNR encryption

In order to address above challenges, we may need to preserve the length and formats of the data types to avoid any validation failures in the application stack. These challenges could be solved with our recently proposed FNR encryption scheme. FNR is flexible encryption scheme that does not expand the length of input data upon encryption.

Blue Print

The blue print of the scheme is based on well studied theoretical constructs called as Feistel networks and Pair-wise independent functions. While there are many similar schemes proposed based on Feistel networks [1][2], the one proposed by Naor and Reingold [3] is proven to provide good security bounds than classic Feistel networks. We have modified it to make the scheme more flexible for practical implementation without losing the security guarantees. More about this inside our specification.

Tweakable

Preserving Formats

In order to preserve the formats of input data types we need ranking functions (along with length preserving encryption schemes). Ranking functions, as the researchers say[2], is a folklore approach to preserve the formats of the data types.

For example, an IPv4 address could be ranked as a 32 bits integer. The ranked integer is then encrypted using a block cipher like FNR to result in another 32 bits integer. The resultant cipher text is converted back to dotted notation of IPv4 address in order to preserve the format. Similar approach could be pursued for other data types like IPv6, MAC addresses etc. Note that since IPv6 address is 128 bits in length traditional AES-128 itself could be used to both encrypt and preserve the IPv6 address format.

For input data types such as Email addresses the ranking technique does not hold good though. A trivial approach to preserve the formats of email addresses is to encrypt user id and domain separately but that may not be secure enough. For data types like usernames , arbitrary short strings of PII (Personally Identifiable Information) nature, but no specific format, could be encrypted as is with FNR scheme.

Anonymization for Cloud

When FNR is used in ECB mode, it realizes a deterministic encryption scheme. Like all deterministic encryption methods, this does not provide semantic security, but determinism is needed in situations where anonymizing telemetry and log data.

Especially in cloud based network monitoring scenarios it is necessary to anonymize the sensitive internal IPv4 addresses in NETFLOW/IPFIX packets while retaining the ability to perform analytics and correlations needed for network monitoring.

Imagine a cloud based networking monitoring application that correlates NETFLOW packets with weblogs and/or syslogs in order to identify any malicious behavior. An anonymized IPv4 address from a NETFLOW packet may be needed to be correlated with events originating from a firewall or IPS sensor. In such scenarios deterministically encrypting an internal IPv4 address would be useful to ensure successful correlations while preserving the privacy of data in cloud.

Searchable Encryption

This also lends itself nicely to achieving searchable encryption operations such as provided in the cryptdb project. Due to the length preserving nature in FNR, it is a better fit in some scenarios than cryptdb, as the cryptdb method expands the data size, resulting in bandwidth and storage savings.

References

Acknowledgements

Keywords: block cipher, length preserving, format preserving, cloud privacy, data anonymization, searchable encryption