ASN.1
- Abstract Syntax Notation One
CRL - Certificate Revocation List
DCE - Distributed Computing Environment
DER
– Distinguished Encoding Rules
DES
– Data Encryption Standard
IIOP
– Internet Inter-ORB Protocol
PEM - Privacy Enhanced Mail
PKC - Public Key Cryptography
PKCS - Public Key Cryptography Standard
PKI – Public Key Infrastructure
RSA - Ronald Rivest, Adi Shamir, and Leonard Adieman
SHA - Secure Hash Standard
SSL - Secure Socket Layer
ASN.1 is a notation
for describing abstract types and values. It is an international standard
widely used in the specification of communication protocols. It is a
language for describing structured information – information intended to be
conveyed across some interface or communication medium. It is also a data
definition language, allowing a designer to define the parameters in a protocol
data unit, without concern as to how they are encoded for transmission.
The
“One” of ASN was named by ISO to leave open the possibility of a better
language version. There are 20 built-in data types, such as BOOLEAN,
INTEGER, ENUMERATED, REAL, BIT STRING, OCTET, STRING, and others.
With ASN.1, the
protocol designer can view and describe the information and its structure at a
higher level and need not concerned with how it is represented while in
transit. An ASN.1 compiler provides run-time code to convert an instance
of user or protocol information to bits. The BER (Basic Encoding Rules)
were standardized as a companion to ASN.1. What BER does is provide rules for
representing ASN.1 data types as strings of zeros and ones.
When the encoding
rules were separated from the notation, they were dubbed the Basic Encoding
Rules (BER), with the idea that there might be justification for defining
different sets of encoding rules. Basically, these are rules for representing
objects as strings of ones and zeros. The relation of BER to ASN.1 is that BER
describes how to represent or encode values of each ASN.1 type as a string of
eight-bit octets.
There are two
additional rules, Canonical and Distinguished Encoding Rules. The first are
designed to reduce options for encoding and thus reduce decoding computational
overhead, and the second are exactly targeted at reducing line overhead. They
provide line efficiency at the cost of processing overhead.
The BER generate
encodings which are of a class known as type - length - value (TLV), so called
because the basis of encoding is a structure made up of those three parts. Many
protocols employ encoding schemes of this general kind. With BER,
the encoding of every data value in an abstract syntax in three parts:
identifier (I), length (L) and contents (C).
The
identifier conveys three pieces of information: the tag class of the
data value being conveyed; the tag number, the form of the encoding - whether
it is primitive or constructed.
The
length (together with the form) allows the end of the contents to be
found. The receiving system need not understand the tag to find the end of the
contents, and this allows an encoding to be skipped if it cannot be decoded.
The
content is the substance of the encoding, conveying the actual value.
When the form of the encoding is primitive, the content is simply a series of
octets (zero or more) and when the form is constructed, the content is a series
of nested encodings, each itself having identifier, length and contents.
There are three
methods to encode an ASN.1 value under BER, the choice of which depends on the
type of value and whether the length of the value is known.
·
Constructed,
definite-length method: This
method applies to simple string types, structured types, types derived simple
string types and structured types by implicit tagging, and types derived from
anything by explicit tagging.
·
Constructed,
indefinite-length method:
This method applies to simple string types, structured types, types derived
simple string types and structured types by implicit tagging, and types derived
from anything by explicit tagging.
A certificate is a digital document
that vouches for the identity and key ownership of an individual, a computer
system (or a specific server running on that system), or an organization.
The format for a certificate is
defined by the ITU standard X.509. According to this standard, a certificate
contains information on the individual requesting the certificate and on the CA
that issued the certificate.
A certificate consists of two
parts: the data within the certificate, and the signature of the CA that issued
the certificate.
A data in a certificate contains
the following information:
·
the version number,
for compatibility with future revisions of the X.509 standard
·
the serial
number of the certificate (every certificate issued from a CA must have a
unique serial number)
·
the signature
algorithm used by the CA (for example, PKCS #1 MD5 with RSA Encryption)
·
the
distinguished name of the CA issuing the certificate (for example, CN=My
Certificate Authority, OU=My Division, O=My Company,C=US)
·
the period
during which the certificate is valid (for example, between November 15, 1996
and November 15, 1997)
·
the
distinguished name of the certificate subject (for example, CN=Jane Doe, OU=My
Division, O=My Company, C=US)
·
information
about the public key that is being certified; this information includes
o the public-key algorithm
o a bit-string representation of the public
key (applies to RSA keys only)
·
(Optional)
Special extensions containing additional information (specified in version 3 of
the X.509 standard; see "Certificate extensions")
The second part of the certificate
includes both the signature of the CA that issued the certificate and the
signature algorithm used by the CA to generate the digital signature (for
example, PKCS #1 MD5 with RSA Encryption). Anyone receiving the certificate can
use the signature algorithm to verify that the certificate was signed using the
CA's private signing key.
A CA is an entity authorized to
issue certificates. Certificates are signed by CAs to verify authenticity.
·
http://www.verisign.com - Verisign
·
http://www.thawte.com/certs - Thawte
Consulting
·
http://www.cost.se - COST
·
http://www.xcert.com - Xcert Software Inc
·
http://www.entrust.com - Entrust
Technologies (was Nortel)
·
http://www.surgeons.co.za/certificate.html
- BiNARY SuRGEONS
·
http://www.keywitness.ca - Keywitness
·
http://www.softforum.co.kr/h-sf -
SoftForum
·
http://www.cybertrust.gte.com - GTE
CyberTrust
·
http://www.compusource.co.za
·
http://www.certisign.com.br - Certisign
Certificadora Digital Ltda
·
http://eurosign.com EuroSign
·
http://www.belsign.be Belsign
Certificate Authorities not only issue
certificates, but also manage them. This means that they determine how long
certificates are valid, renew them, and keep lists of certificates that have
been issued but are no longer valid (certificate revocation
lists, or CRLs).
The responsibility for issuing
certificates can be delegated by setting up subordinate CAs. The X.509 standard
includes a model for setting up a hierarchy of CAs. In this model, the root CA
is at the top of the hierarchy and has a self-signed certificate. The CAs that
are directly subordinate to the root CA have CA certificates signed by the root
CA. CAs under the subordinate CAs in the hierarchy have their CA certificates
signed by the subordinate CAs.
A certificate chain consists of a
certificate, the certificate of the CA that signed the certificate, the
certificate of the CA that signed the CA certificate, and so forth. A
certificate chain ends with the CA certificate of the root CA.
Revocation data can
be published in a CRL (certificate revocation list- a signed list of certificate
serial numbers), a CRDP (certificate revocation distribution point - consists
of partitioned CRLs) or an OCSP (online certificate status protocol - a
client/server protocol used to query a VA (validation authority) for
certificate status).
A CRL is simply a list of certificate serial numbers signed by the CA. Every
certificate has a unique serial number assigned to it by the CA; this number is
part of the signed certificate and cannot be altered. When an application
attempts to validate the certificate, it needs only to look up the serial
number in the CRL associated with the signing CA. However, getting the CRL is a
separate problem. Minimally, some applications may import CRLs via files or
through some other mechanism, such as FTP or HTTP. Obviously, the process of
importing files doesn't scale well and is best used for pilot programs or
troubleshooting. Ideally, applications should be able to query the CRL from the
signing CA's directory via LDAP. Note that generic client applications, such as
Netscape Communications Corp.'s Navigator, can't query or even download CRLs.
In fact, client applications don't do any revocation checking at all. Client
applications need to be capable of checking CRLs.
CRLs,
while widely supported, pose two potential problems: They may become very large
in size, and they may not be published often enough.
CAs
publish revocation data to OCSP responders in a variety of ways. CRLs can
be pushed or pulled into the OCSP responder, or the revocation data can be
published directly. The responder must trust the publishing CA's certificate to
confirm the information published to it is from the correct source. The client
must trust the responder that is signing the OCSP responses. Revocation
publishing time also impacts applications that are using your CA for trust,
because many applications use CRLs to validate certificates. Because CRLs are
published periodically, the application can download a new CRL as soon as it is
published. If you change the publication period, however, the trusting
applications will need to update their time schedules to ensure they have the
latest CRL. Many CAs allow revocation data to be published manually, but that
doesn't mean all applications will take advantage of the data, because those
apps may not have retrieved the updated CRL yet.
Certificates
can be revoked, or they can be temporarily suspended. Baltimore UniCert,
Entrust Authority, VeriSign, Xcert Sentry CA and other CAs all support
suspension. Suspension is used when revocation is too drastic. For example, if
a user forgets the PIN to his or her certificate store or misplaces his or her
PKI token, the associated certificates can be suspended until the user recalls
the PIN or finds the token. The suspended certificate will be placed on the
revocation list but can later be restored. Suspension suffers from the same
time-lag problem as revocation, however, both for getting on the revocation
list and for getting off.
DCE is a set of
integrated system services that provide an interoperable and flexible
distributed environment with the primary goal of solving interoperability
problems in heterogeneous, networked environments. It is called the “middleware”
or “enabling technology”. It is not intended to exist alone, but instead
should be bundled into a vendor's operating system offering, or integrated in
by a third-party vendor. DCE is not an application; it is used to build
custom applications or to support purchased applications.
DCE services are
organized into two categories:
1. Fundamental
distributed services provide tools for software developers to create the
end-user services needed for distributed computing. They include:
o Remote Procedure
Call
o Directory services
o Time service
o Security service
o Thread service
2. Data-sharing
services provide end users with capabilities built upon the fundamental
distributed services. These services require no programming on the part of the
end user and facilitate better use of information. They include
o Distributed
file system
o Diskless support
The DCE supports
International Open Systems Interconnect (OSI) standards, which are critical to
global interconnectivity. It also implements ISO standards such as CCITT X.500,
Remote Operations Service Element (ROSE), Association Control Service Element
(ACSE), and the ISO session and presentation services. The DCE also supports
Internet standards such as the TCP/IP transport and network protocols, as well
as the Domain Name System and Network Time Protocol provided by the Internet.
DER
is a subset of BER, intended for
applications in which a unique octet string encoding is needed, as is the case
when a digital signature is computed on an ASN.1 value. DER is defined in
Section 8.7 of X.509
The BIT STRING type denotes an arbitrary string of bits
(ones and zeroes). A BIT STRING value can have any length, including zero. This type is a string type.
ASN.1 Notation:
Example: X.509's SubjectPublicKeyInfo type has a component of type BIT STRING:
SubjectPublicKeyInfo
::= SEQUENCE {
algorithm
AlgorithmIdentifier,
publicKey
BIT STRING }
DER encoding. Primitive. The contents octets are as for a
primitive BER encoding, except that the bit string is padded with zero-valued
bits. Example: The DER encoding of the BIT STRING value "011011100101110111" is
03 04 06 6e 5d c0
03
is the identifier octets, 04 is the length octets, 06 6e 5d c0 are the content octets,
in which 06 means the padding bits, “6e 5d c0” means “0110 1110 0101 1101 11” +
“00 0000”.
Introduction
·
For each given
message, the key is chosen at random from among this enormous number of keys. [1]
·
Data can be
recovered from the cipher only by using exactly the same key used to encipher
it. (symmetric key)
·
Introduced in
1970s, it was hard to be broken by the computers at that time.
Advantage
Disadvantage
·
Everyone who
knows the key is able to decrypt the message, so it needs a good way to
transmit the key.
Conclusion
DES is still widely use in crypto
applications. The key problem is how to transmit the KEY. Since RSA was
introduced, it is usual to encrypt the messages with DES and encrypt the DES
Key using RSA.
The general consensus is that DES is no longer strong enough for today's encryption needs. Therefore, NIST is currently working on a new standard, the Advanced Encryption Standard (AES), to replace DES. In the intermediate stage, triple-DES is the encryption standard
To
sign a message, the sender does a computation involving both his private key
and the message itself. The output is called a digital signature and is
attached to the message. To verify the signature, the receiver does a computation
involving the message, the purported signature, and the sender’s public key. If
the result is correct according to a simple, prescribed mathematical relation,
the signature is verified to be genuine; otherwise, the signature is
fraudulent, or the message may have been altered.
A digital signature is
created by encrypting a digest of the message, along with other information
such as a sequence number, with the sender's private key. Anyone may decrypt the
signature using the public key, but since only the signer knows the private
key, only they may have signed it. Including the digest in the signature means
the signature is only good for that message, and also ensures the integrity of
the message since no one can change the digest and still sign it. To ensure
that somebody cannot intercept the signature and reuse it later, the signature
contains a unique sequence number.
In the Internet world, routing is done by IP
(the 4-digit number), for example 28.2.185.234. This number is hard to remember
because there are many IPs on the Internet. You will not want to remember the
IPs of yahoo, AOL or MSN. That’s why we need DNS.
Introduction
IIOP is a standard
protocol whose use guarantees that CORBA-enabled objects can
Netscape and its
partners IBM, Sun and Oracle see the power of CORBA and want to make
Internet-based services as widely available as Internet-based content is
today. Netscape has committed to integrating CORBA and IIOP into every
client and server solution it sells from now on
Advantage
·
IIOP makes it
possible to develop a programming function once (i.e., an "object")
and then expose it to the rest of the company. Developers can reuse objects
through standard Interface Definition Language (IDL) interfaces. Additionally,
IIOP is a tested technology that has been used for years in some of the largest
corporations.
Disadvantage
Layered Architecture
Diagram
|
|
|
ORB |
|
IIOP |
|
TCP |
|
IP |
|
Ethernet |
Java Compiler provided by Sun Microsystems. [3]
Development Files and Architecture
The root directory of the JDK software installation.
Contains copyright, license, and README files. Also includes: src.jar -- the archive of source files for all the
classes that make up the Java platform's core API.
·
c:\jdk1.2\bin
The
executable files for the development tools contained in the Java Development
Kit.
·
c:\jdk1.2\lib
Files used
by the development tools.
·
c:\jdk1.2\jre
The root
directory of the Java runtime environment used by the JDK development tools.
·
c:\jdk1.2\jre\bin
Executable files and DLLs for tools and libraries
used by the Java platform. This directory does not need to be in the PATH
environment variable.
·
c:\jdk1.2\jre\bin\classic
Contains the Windows DLL files used by the classic
VM. When newer virtual machines are available, their DLLs will be installed in
a new subdirectory of jre/bin.
·
c:\jdk1.2\jre\lib
Code libraries, property settings, and
resource files used by the Java runtime environment.
·
c:\jdk1.2\jre\lib\security
Contains
files used for security management. These include the security policy (java.policy) and security properties (Java.security)
files.
___________|____________________ | | | bin lib jre | | __________|___________ java.exe tools.jar | | javac.exe dt.jar bin lib javap.exe _____|____ ________|________ javah.exe | | | | | javadoc.exe java.exe classic rt.jar ext security java.dll | i18n.jar | awt.dll jvm.dll iiimp.jar
Architecture
|
|
|
Java Virtual Machine |
|
Hardware Platform and Operating System |
Compiled Java Programs are bytecode forms
that can’t be executed by machine. JVM is a bytecode interpreter that
translates bytecode to machine code. This is why running Java programs is not
as fast as running C programs. There are 202 packages inside JVM, including
arithmetic operations, stream controlling, data controlling and etc.
·
It is
stack-based design. All the instructions are executed from the stack, not from registers,
so it is not restricted to the number and the format of registers. Basically,
one register is used for the Program Counter to record the sequence of
instructions and several registers are needed for controlling stack.
Disadvantage
A message digest, or one-way hash, is a concise summary of a message being sent. Message digests are used to create short, fixed-length representations of longer, variable-length messages. Digest algorithms are designed to produce unique digests for different messages, and to make it too difficult to determine the message from the digest. They are also designed to make it impossible to find two different messages that create the same digest (to eliminate the possibility of substituting one message for another while still having the same digest).
Message digests are usually included digital signatures.
MD5 is a message-digest
algorithm developed by RSA Laboratories. MD5 produces a 128-bit message digest.
Most existing software applications that handle certificates only support MD5.
Set of standards to provide security for
e-mail messages sent across the Internet.
There are three levels of security:
Its use depends on establishment of
certification authorities that can issue certificates at various levels of
security, such as "High security", "Medium security", or
"Low or No security".
Also known as Asymmetric Cryptography. It is
a cryptosystem in which messages are encrypted and decrypted by using a
combination of keys, one available to the general public and one private.
Anyone
may encrypt a message using the public key, but only the owner of the private
key will be able to read the message.
Set of standards developed by RSA Data Security,
Inc. for enciphering of data and messages.
·
PKCS #1: RSA Cryptography Standard
·
PKCS #2: Note below
·
PKCS #3: Diffie-Hellman Key Agreement Standard
·
PKCS #4: Note below
·
PKCS #5: Password-Based Cryptography Standard
·
PKCS #6: Extended-Certificate Syntax Standard
·
PKCS #7: Cryptographic Message Syntax Standard
·
PKCS #8: Private-Key Information Syntax Standard
·
PKCS #9: Selected Attribute Types
·
PKCS #10: Certification Request Syntax Standard
·
PKCS #11: Cryptographic Token Interface Standard
·
PKCS #12: Personal Information Exchange Syntax Standard
·
PKCS #13: Elliptic Curve Cryptography Standard
·
PKCS #15: Cryptographic Token Information Format
Standard
Note: PKCS #2 and PKCS #4 have been incorporated into PKCS #1
Public-key infrastructure is the combination of software,
encryption technologies, and services that enables enterprises to protect the
security of their communications and business transactions on the Internet.
PKIs integrate digital certificates, public-key cryptography, and certificate authorities into a total, enterprise-wide network security architecture. A typical enterprise's PKI encompasses the issuance of digital certificates to individual users and servers; end-user enrollment software; integration with corporate certificate directories; tools for managing, renewing, and revoking certificates; and related services and support.
RSA is a public key cipher. It is said to be
the only completely secure public key system. It is based on the use of prime numbers
and the following concept: If p and q are prime numbers, in the
equation p * q = r it is easy to obtain r from p and q,
but it is not easy to obtain p and q from r, given that p
and q are at least 50 digit numbers.
The algorithm works as follows:
A hashing algorithm is used to produce a
condensed version of a message, which can be then signed electronically by the
sender. This is a one-way function. It is used for authentication of a message
sent by PKC. A hash is also called a Message Digest.
SHA-1 is a message-digest algorithm developed by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). SHA-1 produces an 160-bit message digest. The algorithm is slower than MD5, but the message digest is larger, which makes it more resistant to "brute force" attacks, which choose messages at random to in an attempt to generate the same message digest.
SSL is a protocol that is typically bundled
with a web browser. It
is designed to provide privacy between two communicating applications (a client
and a server). The protocol is designed to authenticate the server, and optionally
the client. It is designed to
work always as a host behaving as a client and one behaving as a server.
The three elements of SSL are:
There
is also an optional protocol that allows a server to ask for a public key
certificate from a client.
One common use of SSL is for securing web
HTTP communication between a browser client and a web server. This case does
not preclude the use of non-secured HTTP. The secure version uses URLs that
begin with "https" instead of "http", and a different
server port (by default 443). The browser will maintain client certificate
private keys when they are generated, and display an indicator if a secure
connection is being used.
The advantage of the SSL
Protocol is that it is "application protocol" independent. A
"higher level" application protocol (e.g. HTTP, FTP, TELNET, etc.)
can layer on top of the SSL Protocol transparently.
The protocol is designed to
support a range of choices for specific algorithms used for cryptography,
digests, and signatures. This allows algorithm selection for specific servers
to be made based on legal, export or other concerns, and also allows the
protocol to take advantage of new algorithms. Choices are negotiated between
client and server at the start of establishing a protocol session.
SSLeay is a free implementation of Netscape's Secure Socket Layer - the software encryption protocol behind the Netscape Secure Server and the Netscape Navigator Browser.
SSLeay implements the following encryption algorithms: DES, RSA, RC4, IDEA, and Blowfish. The base release of SSLeay includes support for building on Unix, DOS, Windows (WIN16, WIN32), and VMS.
SSLeay-0.6.6 (SSLeay-0.6.tar.gz, SSLeay-0.6.tar.patch1) is a free non-commercial implementation of SSL 2.0 (support for 3.0 is under development). It includes a public key implementation that may be used outside the United States. In the United States, RSARef or BSAFE3.0 must be used due to patent requirements. SSLeay offers an inexpensive way to get started with SSL.
SSLeay may be installed and used for the following distinct but related purposes:
1. Managing certificates
2. Implementing SSL in a server
Symmetric cryptography, also known as Conventional Cryptography, requires the sender and receiver to share a key, a secret piece of information that may be used to encrypt or decrypt a message. Only those who have the key (the sender and receiver) may read the message.
The problem with symmetric cryptography is key management: assuring that sender and receiver are using the same key, and that nobody except the sender and the receiver know this key. This is why Public Key Cryptography is widely used; it doesn’t require sharing this secret key.
1. http://www.itl.nist.gov/fipspubs/fip46-2.htm
2. Cryptosystems http://members.home.com/b-carlson/research.html
3. JDK files http://www.sun.com/research/forest/opj/docs/tooldocs/win32/jdkfiles.html
4. A
layman’s guide to a subset of ASN.1, BER, and DER http://www.columbia.edu/~ariel/ssleay/layman.html
5. IIOP specification http://www.blackmagic.com/people/gabe/iiop.html
6. IIOP developer Central http://developer.netscape.com/tech/corba/index.html
7. IIOP and the Distributed Objects Model http://home.netscape.com/columns/techvision/iiop.html
8. Encyclopedia of Cryptology. David E. Newton.
Abc-Clio; ISBN: 0874367727. November 1997.
9. Internet Cryptography. Richard E. Smith. Addison-Wesley. ISBN: 0-201-92480-3. 1997.
10. Public Key Cryptography Standards http://www.rsasecurity.com/rsalabs/pkcs/
11. Understanding Certificates http://developer.netscape.com:80/docs/manuals/certificate/certagnt/overview.htm