NetSP/Krypto-Knight
Key Distribution and Authentication
Presented by: Charlie Perkins
Contact: Amir Herzberg
amir@watson.ibm.com
IBM T. J. Watson Research Center
Hawthorne, New York
NetSP/KryptoKnight
- Symmetric key distribution and authentication
- `Kerberos-like' but layer-3-able, versatile
- Simple, efficient computation and communication
- Flexible, dynamic connectivity requirements
- Analysis of security
- Available, open product on AIX, OS/2 GSS-API, free object of client
and demo server
- Exportable
- Does not require clock synchronization
___________________________________________________________
NetSP | Kerberos | Public-key
___________________|___________________|___________________
| |
Key distribution, | Key distribution, | Key distribution,
Authentication | Authentication, | Authentication,
| Access control | Signatures
-------------------|-------------------|-------------------
Secure Server | Secure server | Req. only
| and sync. clocks | secure off-line
| | certification srvr
-------------------|-------------------|-------------------
64-240 b/pkt | 265-1024 b/pkt | 1024-2048 b/pkt
-------------------|-------------------|-------------------
10^-5 sec/pkt | 10^-4 sec/pkt | 10^-1 s/pkt
-------------------|-------------------|-------------------
Exportable | Crypto routines | Non-exportable
| not exportable |
-------------------|-------------------|-------------------
All configurations | Only A-AS-A-B-A | n/a
___________________|___________________|___________________
Versatile Connectivity Configurations
Figure
(GIF - 10134 bytes)
2PP Protocol: Auth + Key Exchange
Figure
(GIF - 12676 bytes)
- Proven security for strong adversary
- Short messages (128 bits), minimal computations
- Simple extensions to exchange key, etc.
Simple 3PP: Key Distribution by A-B-AS-B-A
Figure
(GIF - 7346 bytes)
Power Functionality
- Implemented:
- Single sign-on: protects (weak) passwords
- RACF support
- Secure password update
- Real soon now:
- `Skinny Client' under MS-DOS, Windows
- Smart-card support
- Have protocols (please feedback):
Why semi-secure servers?
- Common sense: `nothing stands forever' and
`you can't fool everybody at once'
- Existing solutions are limited, incomplete:
- Tamper-proof hardware is expensive, `closed,' inflexible
- Trusted servers are expensive, unavailable...
- Public key is expensive, and still needs secure certification
- Viruses, trapdoors, and internal fraud
Algorithm remains secure as long as even one system is not compromised.