Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

IBM System Digital Signature Data Structure Format

IP.com Disclosure Number: IPCOM000104664D
Original Publication Date: 1993-May-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 172K

Publishing Venue

IBM

Related People

Johnson, DB: AUTHOR [+4]

Abstract

This article describes the data structure format used in IBM* System Digital Signatures. Documenting this format ensures that users of an arbitrary cryptosystem supporting the same public key algorithm and system digital signature record format are able to meet potential interoperability requirements associated with the use of IBM System Digital Signatures.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

IBM System Digital Signature Data Structure Format

      This article describes the data structure format used in IBM*
System Digital Signatures.  Documenting this format ensures that
users of an arbitrary cryptosystem supporting the same public key
algorithm and system digital signature record format are able to meet
potential interoperability requirements associated with the use of
IBM System Digital Signatures.

      Fig. 1 illustrates a network of communicating cryptographic
systems A, B, C, etc.  Each cryptographic system has a capability to
generate and distribute cryptographic keys to each other
cryptographic system.  These cryptographic keys may be used to
encrypt and distribute other cryptographic keys according to a
prescribed key distribution protocol or they may be used to generate
digital signatures on data, which may then to sent to another
cryptographic system where they are verified.

      Fig. 2 illustrates a typical cryptographic system, say A,
consisting of a cryptographic facility (CF) 1 capable of executing a
set of cryptographic instructions, a key storage (KS) 2 for the
storage of encrypted keys, a cryptographic facility access program

(CFAP) 3 capable of executing a set of high-level cryptographic
functions, and application programs (APPLs) 4 which make use of the
CFAP via an Application Programming Interface (API).  The
cryptographic facility 1 contains cryptographic algorithms consisting
of the Data Encryption Algorithm (DEA) 5 and the RSA public key
algorithm 6, each capable of performing encrypt and decrypt
operations.  The CF also has a capability to generate DEA and RSA
keys.  The CFAP 3 contains a function to generate a pair of RSA keys
(a public key and a private key) which is called PKA Key Generate
(PKG).  The CFAP 3 contains a set of cryptographic functions which,
as a by-product of function execution, generate a system digital
signature.  They include the Public Key Export (PKE) function and the
DEA Key Generate (DKG) function.  The CFAP 3 also contains a set of
cryptographic functions which, as a by-product of function execution,
verify a system digital signature.  They include the Public Key
Import (PKI) function and the DEA Key Import (DKI) function.  The
CFAP 3 also contains a Application Signature Generate (ASG) function
for producing application digital signatures, which are different
from system digital signatures, and it contains a Application
Signature Verify (ASV) function for verifying application digital
signatures.  The difference between system digital signatures and
application digital signatures is explained below.

      Fig. 3 illustrates two cryptographic systems A and B and the
functional relationship that exists between the CFAP functions.  For
example, a system digital signature produced by a Public Key Export
function at A is processed in a Public Key Import function at B.  A
system digital signature produced by a DEA Key Generate function at A
is proc...