crypto class design

So... supposing I was going to design a crypto library for
use within
a financial organization, which mostly deals with credit
card numbers
and bank accounts, and wanted to create an API for use by
developers,
does anyone have any advice on it?

It doesn't have to be terribly complete, but it does have to
be
relatively easy to use correctly (i.e. securely).

I was thinking of something like this:

class crypto_api
{
    ...
    // developers call these based on what they're trying to
do
    // these routines simply call crypto_logic layer
    Buffer encrypt_credit_card(Buffer credit_card_number,
key_t key);
    Buffer encrypt_bank_account(Buffer bank_account, key_t
key);
    Buffer encrypt_other(Buffer buffer, key_t key);
    ...
};

class crypto_logic
{
    ...
    algo_default = ALGO_AES256CBC;
    // encrypt with a given algorithm
    Buffer encrypt(Buffer buffer, key_t key, algo_t aid =
algo_default);
    // calls different routines in crypto_implementation
layer depending on algorithm used
    Buffer decrypt(Buffer buffer, key_t key);
    ...
};

class crypto_glue
{
    ...
    // calls routines in libraries such as OpenSSL
    // mostly wrappers that translate between our data types
and theirs
    Buffer aes256cbc-encrypt(...);
    Buffer aes256cbc-decrypt(...);
    ...
};

The general idea is that crypto_api provides domain-specific
APIs that
are easy for anyone to understand, that the logic layer
allows for the
selection of different algorithms, and the glue layer is
basically a
translation layer to underlying libraries.

It is very important that the API remain stable, because the
code
base is large and owned by various groups.

One thing that I'm wondering is how to indicate (e.g.) the
overhead in
terms of padding, or whatever, for various algorithms... or
if it
matters.  The old code had some really disturbing practices
like
assuming that the output buffer was 16 octets bigger, and
stuff like
that... scary.

Intend to skim the OpenSSL design and Gutmann's "Design
of a
Cryptographic Security Architecture" for ideas.

Comments?
-- 
In God We Trust, All Others Must Provide Source Code
<URL:https://ww
w.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my email blacklist, email johnsubspacefield.org.

While there are many different ways to approach encryption
and decryption of sensitive data, you may want to consider
how you plan to manage the encryption keys before you go
down this path.

It sounds like you are establishing the foundation of a
class
library for a large financial organization.  Not having an
enterprise-class key-management system can prove to be
their
downfall, no matter how efficiently you encrypt/decrypt
data.

I would encourage you to look at an effort at OASIS that is
standardizing on a Symmetric Key Services Markup Language
(SKSML) for acquiring key-management services from an
Enterprise Key Management Infrastructure (EKMI):

http://www.oasis-open.org/committees/tc_home.php?
wg_abbrev=ekmi

Not only does this Technical Committee have the support of
Visa, the US Dept. of Defense, Wells Fargo, Red Hat and 28
other companies/individuals, this schema is also going to
be
supported by the IEEE 1619.3 Working Group that is creating
a key-management protocol for storage devices (see the list
of Announcements on the OASIS web-page for how they will
integrate to an EKMI).

An open-source implementation of SKSML is available at
http://www.strongkey.org
with an example application that
shows column-level encryption of - interestingly - credit
card numbers in an RDBMS.

The open-source implementation is based on Java; if you
need
C/C++, you can either choose to create your own client
library
that implements SKSML (and use the open-source SKMS for the
server) or contact me privately for an alternative
solution.

Arshad Noor
StrongAuth, Inc.

travis+ml-cryptographysubspacefield.org wrote:
> So... supposing I was going to design a crypto library
for use within
> a financial organization, which mostly deals with
credit card numbers
> and bank accounts, and wanted to create an API for use
by developers,
> does anyone have any advice on it?
> 
> It doesn't have to be terribly complete, but it does
have to be
> relatively easy to use correctly (i.e. securely).
> 
> I was thinking of something like this:
> 
> class crypto_api
> {
>     ...
>     // developers call these based on what they're
trying to do
>     // these routines simply call crypto_logic layer
>     Buffer encrypt_credit_card(Buffer
credit_card_number, key_t key);
>     Buffer encrypt_bank_account(Buffer bank_account,
key_t key);
>     Buffer encrypt_other(Buffer buffer, key_t key);
>     ...
> };
> 
> class crypto_logic
> {
>     ...
>     algo_default = ALGO_AES256CBC;
>     // encrypt with a given algorithm
>     Buffer encrypt(Buffer buffer, key_t key, algo_t aid
= algo_default);
>     // calls different routines in
crypto_implementation layer depending on algorithm used
>     Buffer decrypt(Buffer buffer, key_t key);
>     ...
> };
> 
> class crypto_glue
> {
>     ...
>     // calls routines in libraries such as OpenSSL
>     // mostly wrappers that translate between our data
types and theirs
>     Buffer aes256cbc-encrypt(...);
>     Buffer aes256cbc-decrypt(...);
>     ...
> };
> 
> The general idea is that crypto_api provides
domain-specific APIs that
> are easy for anyone to understand, that the logic layer
allows for the
> selection of different algorithms, and the glue layer
is basically a
> translation layer to underlying libraries.
> 
> It is very important that the API remain stable,
because the code
> base is large and owned by various groups.
> 
> One thing that I'm wondering is how to indicate (e.g.)
the overhead in
> terms of padding, or whatever, for various
algorithms... or if it
> matters.  The old code had some really disturbing
practices like
> assuming that the output buffer was 16 octets bigger,
and stuff like
> that... scary.
> 
> Intend to skim the OpenSSL design and Gutmann's
"Design of a
> Cryptographic Security Architecture" for ideas.
> 
> Comments?

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

In my experience of doing security evaluations for large
financial
institutions in AsiaPac, I suspect the biggest problem
you'll face in
doing this is hubris from the app developers.  I don't know
why, but
these guys so often have a problem taking advice, at least
in my
experience (which now covers ~15 different financial
institutions in 4
countries.)

The level of ignorance runs deep, and almost without
exception, most
don't see any complexity in crypto protocols or
implementation, and have
a strong "security by obscurity" mentality.  Oh,
and "roll your own"
algorithms are surprisingly common. I've even offered to do
1st order
algorithm reviews in a couple of cases, but been told that
revealing the
algorithm compromised it's security.  "And you don't
think that's a
problem in itself?"  "No."

So, good luck.  I personally have a boilerplate risk
disclosure section
which basically says "your in-house app developers know
squat about
crypto, and you're at risk if you're trusting their designs
and
implementation as a consequence."  It's a bit nicer
phrased, but that's
the gist of the ~4 page section.

Ian.

-----Original Message-----
From: owner-cryptographymetzdowd.com
[mailto:owner-cryptographymetzdowd.com] On Behalf Of
travis+ml-cryptographysubspacefield.org
Sent: Tuesday, 18 December 2007 3:39 AM
To: Cryptography
Subject: crypto class design

So... supposing I was going to design a crypto library for
use within a
financial organization, which mostly deals with credit card
numbers and
bank accounts, and wanted to create an API for use by
developers, does
anyone have any advice on it?

It doesn't have to be terribly complete, but it does have to
be
relatively easy to use correctly (i.e. securely).

I was thinking of something like this:

class crypto_api
{
    ...
    // developers call these based on what they're trying to
do
    // these routines simply call crypto_logic layer
    Buffer encrypt_credit_card(Buffer credit_card_number,
key_t key);
    Buffer encrypt_bank_account(Buffer bank_account, key_t
key);
    Buffer encrypt_other(Buffer buffer, key_t key);
    ...
};

class crypto_logic
{
    ...
    algo_default = ALGO_AES256CBC;
    // encrypt with a given algorithm
    Buffer encrypt(Buffer buffer, key_t key, algo_t aid =
algo_default);
    // calls different routines in crypto_implementation
layer depending
on algorithm used
    Buffer decrypt(Buffer buffer, key_t key);
    ...
};

class crypto_glue
{
    ...
    // calls routines in libraries such as OpenSSL
    // mostly wrappers that translate between our data types
and theirs
    Buffer aes256cbc-encrypt(...);
    Buffer aes256cbc-decrypt(...);
    ...
};

The general idea is that crypto_api provides domain-specific
APIs that
are easy for anyone to understand, that the logic layer
allows for the
selection of different algorithms, and the glue layer is
basically a
translation layer to underlying libraries.

It is very important that the API remain stable, because the
code base
is large and owned by various groups.

One thing that I'm wondering is how to indicate (e.g.) the
overhead in
terms of padding, or whatever, for various algorithms... or
if it
matters.  The old code had some really disturbing practices
like
assuming that the output buffer was 16 octets bigger, and
stuff like
that... scary.

Intend to skim the OpenSSL design and Gutmann's "Design
of a
Cryptographic Security Architecture" for ideas.

Comments?
--
In God We Trust, All Others Must Provide Source Code
<URL:https://ww
w.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my email blacklist, email johnsubspacefield.org.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

> One thing that I'm wondering is how to indicate (e.g.)
the overhead in
> terms of padding, or whatever, for various
algorithms... or if it
> matters.  The old code had some really disturbing
practices like
> assuming that the output buffer was 16 octets bigger,
and stuff like
> that... scary.

I am not sure I understood what you want but here's my
suggestion.


What about creating a new data type called crypto_card? It
could be
defined like this:

typdef struct crypto_card{
  unsigned char initialization_vector[12];
  unsigned char card_no[20];
  unsigned char checksum[16];
} crypto_card;

Supposed you are using AES and you have a block size of 128.
The idea is
to allocate a buffer for the card (as big as you need) and
then use some
useful padding to make the data fit into 128-bit blocks. If
you want
support for different block sizes make sure your data type
size is a
multiple of 8, 16, and 32.

What I called initialization_vector is a random number. This
way, the
card number will be encrypted to something different each
time. This
prevents eavesdroppers to be able to identify that the same
card is
being used in two transactions.

The checksum provides integrity checks so you don't actually
perform
operations on wrong card numbers.

You could use ASCII chars to represent card numbers so if
your card
number is shorter than twenty digits the NULL character
could indicate
the end of the information.


Is this what you meant?



Luis.


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Mon, Dec 17, 2007 at 10:38:59AM -0600,
travis+ml-cryptographysubspacefield.org wrote:

> So... supposing I was going to design a crypto library
for use within
> a financial organization, which mostly deals with
credit card numbers
> and bank accounts, and wanted to create an API for use
by developers,
> does anyone have any advice on it?
> 
> It doesn't have to be terribly complete, but it does
have to be
> relatively easy to use correctly (i.e. securely).

APIs don't solve security problems, just code re-use
problems. Teaching
smart people how to do threat analysis is a better bet.
Untrained
developers will choose an API that solves the wrong
problem.

> class crypto_api
> {
>     ...
>     // developers call these based on what they're
trying to do
>     // these routines simply call crypto_logic layer
>     Buffer encrypt_credit_card(Buffer
credit_card_number, key_t key);
>     Buffer encrypt_bank_account(Buffer bank_account,
key_t key);
>     Buffer encrypt_other(Buffer buffer, key_t key);

And who does key management? I bet the key will be right
there with
the data on the same disk, probably logged in the clear in
application
logs too...

> The general idea is that crypto_api provides
domain-specific APIs that
> are easy for anyone to understand, that the logic layer
allows for the
> selection of different algorithms, and the glue layer
is basically a
> translation layer to underlying libraries.

Encryption is almost never the problem, design is the
problem, with a
good design, the crypto is already available.

> Comments?

Why yet another crypto library? Invest your energy in
complete designs and
code of realistic show-case solutions to real-world
problems, not APIs.

Good designs will get copied whole-sale, and morphed. If
well documented,
the developers can learn by reading the sample code, and
training can
be based around the approaches taken in the show-case
systems.

When I hear developers demanding "security APIs" I
pretend to be deaf...

-- 

 /" ASCII RIBBON                  NOTICE: If received
in error,
  / CAMPAIGN     Victor Duchovni  please destroy and
notify
  X AGAINST       IT Security,     sender. Sender does not
waive
 /  HTML MAIL    Morgan Stanley   confidentiality or
privilege,
                                   and use is prohibited.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Dec 17, 2007, at 17:38, travis+ml-cryptographysubspacefield.org  
wrote:

> So... supposing I was going to design a crypto library
for use within
> a financial organization, which mostly deals with
credit card numbers
> and bank accounts, and wanted to create an API for use
by developers,
> does anyone have any advice on it?

The one thing that I think is most important is not to use
the "bunch  
of functions" approach, but rather an integrated
approach that  
directly supports the use cases and protects against
misuse.

> Intend to skim the OpenSSL design and Gutmann's
"Design of a
> Cryptographic Security Architecture" for ideas.

There you have examples of both approaches.

Fun,

Stephan

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

| So... supposing I was going to design a crypto library for
use within
| a financial organization, which mostly deals with credit
card numbers
| and bank accounts, and wanted to create an API for use by
developers,
| does anyone have any advice on it?
| 
| It doesn't have to be terribly complete, but it does have
to be
| relatively easy to use correctly (i.e. securely).
| 
| I was thinking of something like this:
| 
| class crypto_api
| {
|     ...
|     // developers call these based on what they're trying
to do
|     // these routines simply call crypto_logic layer
|     Buffer encrypt_credit_card(Buffer credit_card_number,
key_t key);
|     Buffer encrypt_bank_account(Buffer bank_account, key_t
key);
|     Buffer encrypt_other(Buffer buffer, key_t key);
|     ...
| };
| 
| class crypto_logic
| {
|     ...
|     algo_default = ALGO_AES256CBC;
|     // encrypt with a given algorithm
|     Buffer encrypt(Buffer buffer, key_t key, algo_t aid =
algo_default);
|     // calls different routines in crypto_implementation
layer depending on algorithm used
|     Buffer decrypt(Buffer buffer, key_t key);
|     ...
| };
| 
| class crypto_glue
| {
|     ...
|     // calls routines in libraries such as OpenSSL
|     // mostly wrappers that translate between our data
types and theirs
|     Buffer aes256cbc-encrypt(...);
|     Buffer aes256cbc-decrypt(...);
|     ...
| };
| 
| The general idea is that crypto_api provides
domain-specific APIs that
| are easy for anyone to understand, that the logic layer
allows for the
| selection of different algorithms, and the glue layer is
basically a
| translation layer to underlying libraries.
| 
| It is very important that the API remain stable, because
the code
| base is large and owned by various groups.
| 
| One thing that I'm wondering is how to indicate (e.g.) the
overhead in
| terms of padding, or whatever, for various algorithms...
or if it
| matters.  The old code had some really disturbing
practices like
| assuming that the output buffer was 16 octets bigger, and
stuff like
| that... scary.
| 
| Intend to skim the OpenSSL design and Gutmann's
"Design of a
| Cryptographic Security Architecture" for ideas.
| 
| Comments?
Your Buffer class is a step up from using a void*!  You're
not really
using data typing effectively.  Define classes to
encapsulate encrypted
and cleartext data; carefully decide what transitions are
allowed among
them; and define your API around that.  Note that
transitions include
creation and, particularly, deletion - the destructor for
cleartext
should zero the memory.

The above is a simplification.  There are probably more than
two
categories of data.  A better classification might be: 
Encrypted,
cleartext but sensitive, non-sensitive.  In a financial
setting,
"sensitive" may have subdivisions based, for
example, on who is allowed
access.  Should there be some special datatype for keys,
which are about
the most sensitive thing in the system?  (It should probably
be the case
that the common public API's provide no way to export a key,
just a way
to apply it.  Key management should be a separate API that
most
applications don't even use, so you can be sure they can't
(without
cheating, which is of course always possible in C++) leak
them.)

As much as possible, make the actual rules that apply to any
piece of
data in the program (a) transparent to someone reading the
code; (b)
enforceable by a compiler or, second best, the API
implementation.  In
the public API, concentrate on the data and the rules that
govern it.
Particular crypto algorithms and various related choices
should be
hidden within the implementation.  Not only should the API
be easy to
use correctly, it should be as hard as possible to use
*in*correctly!

							-- Jerry

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Wed, Dec 19, 2007 at 08:22:09AM +0100, Luis Martin
wrote:
> I am not sure I understood what you want but here's my
suggestion.

The problem is that client code assumes that there is a
fixed (constant)
relationship between the size of the output and the size of
the input,
and does its own memory allocation for the output, and uses
pointers.

This makes it difficult to change that relationship safely;
I
basically have to track down and change all the calling
code, which
may be near-impossible.

I think the right solution in this case is to pass objects
and not
pointers, unless performance dictates otherwise.

But, are there similar assumptions implicit in the calling
code which
I can avoid through proper design, now?

That having been said, your suggestion for a data type for
this
purpose, with semantically-useful subdivisions, is an
interesting one;
thank you (and everyone else who gave suggestions!)

-- 
In God We Trust, All Others Must Provide Source Code
<URL:https://ww
w.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my email blacklist, email johnsubspacefield.org.

On Dec 17, 2007, at 9:38 AM, travis+ml-cryptographysubspacefield.org  
wrote:

> So... supposing I was going to design a crypto library
for use within
> a financial organization, which mostly deals with
credit card numbers
> and bank accounts, and wanted to create an API for use
by developers,
> does anyone have any advice on it?

I'm curious if your crypto library is to be implemented by
use of  
another one, perhaps an open-source one that I am familiar
with.   
Nowadays I prefer Crypto++ [1].

Regards,

Zooko

[1] http://cryptopp.com/

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

At 06:48 PM 12/18/2007 -0800, Arshad Noor wrote:
>While there are many different ways to approach
encryption
>and decryption of sensitive data, you may want to
consider
>how you plan to manage the encryption keys before you
go
>down this path.

This is prudent.  You should consider how to
"securely" integrate
key management with other important components of a
security
system, such as identity/authentication, policy
adjudication
(policy enforcement should be the encrypt/decrypt itself)
and
audit/logging.  Logging is usually very important in
financial
firms.  You should also carefully think about how to
support
revocation of users (i.e. preventing a revoked user from
using
a key to decrypt/encrypt data), and also to support key
recovery
of encrypted data under proper authority (say to comply
with
a legal warrant.)

Finally, regardless of your design you must carefully weigh
and
assess it's performance, doing the tradeoff between
cryptography
and speed and reliability.  And you need to design it to be
robust
in the face of operational failure.

Just my two cents worth (based on over a decade's worth of
cryptographic based security system design).

- Alex
--

Alex Alten
alexalten.org



------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com