Home Download Learn more Tech Help

Open Crypto Engine

Introduction
Pluggable encryption
Solutions
Interprocess communication
Capabilities
Recommendations

Introduction

The Open Crypto Engine (OCE) lets you use different encryption packages on different operating systems in different languages.
It's an API for encryption plugins with a CORBA interface. You can also bypass CORBA to call the API directly.

There are reference implementation of plugins for Bouncy Castle, GPG, and PGP. Tiger Envelopes is the reference implementation of an OCE client.

OCE is intended primarily for email and file encryption. It uses some library files from Tiger.

Pluggable encryption

Crypto package independent
- Supports Bouncy Castle, GPG, PGP
- For example you can choose PGP today, then instantly switch to GPG tomorrow
Language independent
- Applications and encryption plugins can be in any major language
- OCE itself happens to be in pure Java, but any language can use it
Operating system independent
- Windows
- Mac
- Linux
- Any major operating system

Solutions

Write your code once and choose from multiple encryption packages.
Your application and encryption plugins can be developed in any major language and run on any major OS.
Makes layered encryption easy.
- If just one of the nested encryption packages works, it doesn't matter as much whether the others do.
- Use different keys for each package in case one of them exposes its keys.
For all applications that use OCE, encryption interface bugs can be fixed in one place.

Interprocess communication

OCE supports CORBA because SOAP explicitly bypasses firewalls
Rewards and risks
- CORBA provides extreme OS and language independence.
- But the risk of providing a network interface, no matter how well protected, to secret key operations, and the security risks associated with additional complexity, may not be worth it.
- Developers using Java can get the benefits of OCE without the risks two ways
  - Dynamically, using the crypto.Plugin interface and forName()
  - Directly, importing GPGPlugin, PGPPlugin, etc.
- For users, interprocess comm probably should be an installation choice with a default of "No".
Standards
- CORBA
  - Pros
    - IIOP is easily blocked at the firewall
    - Very well standardized
    - Fiercely platform independent
      - Runs on any major OS
      - Bindings for every major language
      - Platform neutral Interface Definition Language (IDL)
    - IDL is intended to be read and written by humans
    - Automatic code generation from IDL to many languages
    - If you really need SOAP, there's bridge software. It's also easy to write an application specific SOAP front end for CORBA
  - Cons
    - If IIOP does cross the firewall it's a major security risk
      - No encryption
      - CORBASEC with SSL exists, but does not have the same support as IIOP
      - This is much less important than it may appear. Windows machines have almost no protection of any kind, anyway. And since both KDE and GNOME on Linux already use CORBA, OCE does not increase the existing risk on those machines.
    - Smaller mind share than XML/SOAP
    - Microsoft opposition
      - MS perceives CORBA as client-server, which helps Sun, rather than peer-to-peer, which helps them.
    - CORBA is sometimes linked to the deadly word "legacy".
      - There's support for COBOL and PL/1.
      - The standards are only available in PDF, a format designed for dead trees.
- SOAP
  - Pros
    - Because of Microsoft's support, SOAP has a large mind share
    - SOAP on an alternative port is easily blocked at the firewall, and if restricted to SSL it's fairly safe even if it does cross the firewall
    - SSL is trusted to protect money
  - Cons
    - SOAP was explicitly designed to easily slip through firewalls. This is the last thing you want for your encryption software.
      - You don't want someone to easily forge your signature, or read your most private messages.
      - Nor do you want your passphrase wandering all over the net.
      - The best workaround is for the firewall to block some HTTP based on the headers. Most firewalls can't.
      - This is less important on an alternative port
      - SOAP can use SSL, but there's little open source support
    - No standard language bindings means no automatic code generation
      - This is changing. De facto bindings for java exist.
    - Schemas only theoretically can be read and written by humans. They are intended for automated parsing and generation.
    - SSL requires certs for servers
- XML-RPC
  - Simple. Works.
  - No standard use of SSL, but it's easy to do using the Helma Java implementation.
- Other options
  - RMI is Java specific
  - DCOM is just Microsoft's alternative to CORBA

Capabilities

Intended initial applications
- Email security
- File security
Basic operations
- Encrypt
- Decrypt
- Sign
- Verify
- Get signer
To be implemented later
- Key servers
  - Get server
  - List servers
- Public key
  - Get key
  - Get trust of key
    - You don't protect paper mail by sending it in a two ton steel safe. You just wrap it in more paper, an envelope. Even untrusted keys from public keyservers probably beat this standard of security.
      - Only "probably" because compromise of public key servers can be automated
    - Possible trust metrics
      - Explicitly trusted
        
        Good reasons are
        
        You generated the key
        
        You verified the fingerprint by external means such as voice
      - Signed by a trusted key
      - Shortest length of trust path from a trusted key
      - Total trust in path, weighted by trust of intermediate keys or of paths
Add/Edit/Import/Export/etc. of key/keyring/etc. delegated to plugin, since these objects are opaque.
Acts as a license firewall
- Between non-commercial encryption packages and other systems
- Isolates the effects of almost any package's license