Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 08 Issue 52 File 15
---[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 15 of 20
-------------------------[ Technical Guide to Digital Certification
--------[ Yggdrasil
Introduction
~~~~~~~~~~~~
Today's software technology provides not only flexible controls for web pages
and complex remote interaction (ActiveX controls, Java applets and Netscape
plugins) but also offers the possibility of downloading pieces of code for
local execution to extend browsers capabilities. A major issue being the
fact that this code cannot be initially distinguished from malicious code
(virii/trojans, "man in the middle" attacks, forced downgrade, forgery of
electronic documents, etc), disguised as utilities.
The point is that end users do not know who published of a piece of software,
if the code has been tampered with, and what that software will do, (until they
download and execute it). Anyone can create plugins, applets or controls
containing this potentially destructive code or even "intelligent" malevolent
code, able to communicate covertly with a remote server.
Public-key cryptography has produced a number of different implementations
to verify the authenticity of software, network objects, documents and data
transactions (for example, Electronic Funds Transfer) using Digital IDs.
Authenticode Certifications
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Microsoft recently adopted Authenticode technology to sign their ActiveX
based software. Any individual or commercial software publisher desiring
their code to be "trusted" must apply for and receive a Digital Certificate
from an Authenticode Certificate Authority (CA), such as VeriSign. The CA
will request proof-of-identity, and other information, only then will they
verify the publishers credentials (even employing Dun & Bradstreet rating).
After the CA has decided that the publisher meets its policy criteria, it
releases a Certificate (the expected cost is about $500 for a year, plus
additional costs for hardware storage for commercial developers, up to
$12,000).
[ God save the next-generation developers. ]
A Digital Certificate contains the publishers public-key (and other info)
encrypted according to the industry standard X.509 V3 certificate format and
PKCS #7 signed data standards.
The ITU-T recommendation for X.509 states that:
"It would be a serious breach of security if the CA issued a certificate for
a user with a public key that had been tampered with."
All Certificates have an expiration time, but the CA may revoke them prior
to that time if a publisher's private-key or CA's certificate is assumed to
be compromised. The CA may (or may NOT) inform the owner of the certificate.
Revocation Lists
~~~~~~~~~~~~~~~~
The Revocation Lists, also called "black-lists", are held within entries as
attributes of types CertificateRevocationList and AuthorityRevocationList.
Their attribute types are defined as follows:
certificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID id-at-certificateRevocationList }
authorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID id-at-authorityRevocationList }
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL,
signature AlgorithmIdentifier, <----+
issuer Name, |
thisUpdate UTCTime, |
nextUpdate UTCTime OPTIONAL, version 2
revokedCertificates SEQUENCE OF SEQUENCE { only
userCertificate CertificateSerialNumber, (extension)
revocationDate UTCTime, |
crlEntryExtensions Extensions OPTIONAL } OPTIONAL, |
crlExtensions [0] Extensions OPTIONAL }} <----+
Implementation of X.509-3
~~~~~~~~~~~~~~~~~~~~~~~~~
The ITU-T X.509 Directory Specification makes use of a set of cryptographic
systems known as asymmetric Public-Key Crypto-Systems (PKCS). This system
involves the use of two keys (one secret and one public as used in common
public key packages like PGP).
Both keys can be used for encoding: the private key to decipher if the
public key was used, and vice versa (Xp*Xs = Xs*Xp, where Xp/Xs are the
key-encoding/decoding functions).
When applied to Digital Signatures, the public key encryption is used to
encipher the data to be signed after it's passed through a hash function.
Information is signed by appending to it an enciphered summary of the info.
The summary is produced by means of a one-way hash function, while the
enciphering is carried out using the private key of the signer.
For further information about X.509 and certificate types please read
the ITU-T Recommendation X.509 ("The Directory: Authentication Framework").
Windows Trust API
~~~~~~~~~~~~~~~~~
To ascertain an objects reliability under Win32, the WinVerifyTrust() API
function is used, according to its prototype as follows:
HRESULT --------------- Description ---------------
WINAPI
WinVerifyTrust (
HWND hwnd, <>0 to allow user to assist in trust decision
DWORD dwTrustProvider, 0 = provider unknown, 1 = software publisher
DWORD dwActionID, specifies what to verify
LPVOID ActionData information required by the trust provider
)
The HRESULT return code will be TRUST_E_SUBJECT_NOT_TRUSTED if the object
is not trusted (according to the specified action in dwActionID). An error
code more detailed than this could be provided by the trust provider.
Creation of a Digitally Signed message
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PKCS #7 specifies several "types", such as ContentInfo, SignedData and
SignerInfo. Version 1.5 of PKCS #7 describes the ContentInfo type as:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
the content is (or better: MAY be) an octet-stream ASCII string to be passed
to the selected digest algorithm (an example is MD2, see RFC-1321).
The first step is to encode the ContentInfo field according to PKCS #7.
This is the resulting encoded data:
== DATA BLOCK #1 ==
{30 28} 06 09 0x0609: contentType = data
2A 86 48 86 F7 0D 01 07 01 PKCS #7 data-object ID
A0 1B [0] EXPLICIT
04 [msg_len] content = OCTET STRING
[octet stream representing
the ASCII string, msg_len bytes long] <-- value (*)
This (*) data is the input stream to the encoding algorithm (MD2 or other):
(the identifier of the PKCS #7 data object is {1 2 840 113549 1 7 1})
== DATA BLOCK #2 ==
{30 20} 30 0C 0x300C: digestAlgorithm
06 08 2A 86 48 86 F7 0D 02 02 algorithm ID = MD2
05 00 parameters = NULL (0x00)
04 [block_len] digest
[encoded data (MD2 output)]
(the object identifier of the MD2 algorithm is {1 2 840 113549 2 2})
This data is the encoded DigestInfo. It will be encrypted under RSA using
the user's private key.
According to PKCS #1, RSA encryption has two main steps: an encryption data
block is constructed from a padding string and the prefixed message digest;
then the encryption block is exponentiated with the user's private key.
The encryption block EB is the following 64-octet string:
00 01 block type
FF FF FF FF FF FF FF FF FF FF FF FF FF FF padding string
FF FF FF FF FF FF FF FF FF FF FF FF FF
00 separator (0x00)
[here goes the whole DATA BLOCK #2] data bytes (prf. message digest)
Now we need to encode various information: a SignedData value from the inner
ContentInfo value, then the encrypted message digest, the issuer and serial
number of the user's certificate, the certificate data, the message digest
algorithm ID (MD2) and the encryption algorithm ID (PKCS #1 RSA).
The encoded SignedData is:
== DATA BLOCK #3 ==
30 82 02 3D
02 01 01 version = 1
31 [size of inner data block] digestAlgorithms
30 [size]
06 08 2A 86 48 86 F7 0D 02 02 algorithm ID = MD2
05 00 parameters = NULL (0x00)
[ContentInfo data] content = inner ContentInfo
A0 82 01 [size] certificates
[certificate data] user's certificate
31 81 [size] signerInfos
30 81 [size]
02 01 01 version = 1
30 [size] issuerAndSerialNumber
[issuer data] issuer
02 04 {12 34 56 78} size (4), serialNumber (12345678)
30 [alg_size] digestAlgorithm
06 08 2A 86 48 86 F7 0D 02 02 algorithm ID = MD2
05 00 parameters = NULL (0x00)
30 [dig_size] digestEncryptionAlgorithm
06 [sz] rsaEncryption (d.E.A.)
2A 86 48 86 F7 0D 01 01 01
05 00 parameters = NULL (0x00)
04 [data_size] encryptedDigest
[encrypted digestInfo encoded data block]
Finally, a ContentInfo value from this SignedData data block is encoded (once
again, using PKCS #7):
30 82 02 [size]
06 09 2A 86 48 86 F7 0D 01 07 02 contentType = signedData
A0 82 02 [size] [0] EXPLICIT
[here goes the whole DATA BLOCK #3] content = SignedData value
(the object identifier of PKCS #7 signedData is {1 2 840 113549 1 7 2})
PKCS Key Example
~~~~~~~~~~~~~~~~
The following is the full hex dump of the above PKCS #7 encoded key.
HEX Dump -------------------------------------: ASCII Dump ----:
30 82 02 50 06 09 2A 86 48 86 F7 0D 01 07 02 A0 0..P..*.H.......
82 02 41 30 82 02 3D 02 01 01 31 0E 30 0C 06 08 ..A0..=...1.0...
2A 86 48 86 F7 0D 02 02 05 00 30 28 06 09 2A 86 *.H.......0(..*.
48 86 F7 0D 01 07 01 A0 1B 04 19 41 20 64 65 6D H..........A dem
6F 20 43 6F 6E 74 65 6E 74 49 6E 66 6F 20 73 74 o ContentInfo st
72 69 6E 67 A0 82 01 5E 30 82 01 5A 30 82 01 04 ring...^0..Z0...
02 04 14 00 00 29 30 0D 06 09 2A 86 48 86 F7 0D .....)0...*.H...
01 01 02 05 00 30 2C 31 0B 30 09 06 03 55 04 06 .....0,1.0...U..
13 02 55 53 31 1D 30 1B 06 03 55 04 0A 13 14 45 ..US1.0...U....E
78 61 6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61 74 xample Organizat
69 6F 6E 30 1E 17 0D 39 32 30 39 30 39 32 32 31 ion0...920909221
38 30 36 5A 17 0D 39 34 30 39 30 39 32 32 31 38 806Z..9409092218
30 35 5A 30 42 31 0B 30 09 06 03 55 04 06 13 02 05Z0B1.0...U....
55 53 31 1D 30 1B 06 03 55 04 0A 13 14 45 78 61 US1.0...U....Exa
6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61 74 69 6F mple Organizatio
6E 31 14 30 12 06 03 55 04 03 13 0B 41 20 64 65 n1.0...U....A de
6D 6F 20 55 73 65 72 30 5B 30 0D 06 09 2A 86 48 mo User0[0...*.H
86 F7 0D 01 01 01 05 00 03 4A 00 30 47 02 40 0A .........J.0G.@.
66 79 1D C6 98 81 68 DE 7A B7 74 19 BB 7F B0 C0 fy....h.z.t.....
01 C6 27 10 27 00 75 14 29 42 E1 9A 8D 8C 51 D0 ..'.'.u.)B....Q.
53 B3 E3 78 2A 1D E5 DC 5A F4 EB E9 94 68 17 01 S..x*...Z....h..
14 A1 DF E6 7C DC 9A 9A F5 5D 65 56 20 BB AB 02 ....|....]eV ...
03 01 00 01 30 0D 06 09 2A 86 48 86 F7 0D 01 01 ....0...*.H.....
02 05 00 03 41 00 45 1A A1 E1 AA 77 20 4A 5F CD ....A.E....w J_.
F5 76 06 9D 02 F7 32 C2 6F 36 7B 0D 57 8A 6E 64 .v....2.o6{.W.nd
F3 9A 91 1F 47 95 DF 09 94 34 05 11 A0 D1 DF 4A ....G....4.....J
20 B2 6A 77 4C CA EF 75 FC 69 2E 54 C2 A1 93 7C .jwL..u.i.T...|
07 11 26 9D 9B 16 31 81 9B 30 81 98 02 01 01 30 ..&...1..0.....0
34 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 40,1.0...U....US
31 1D 30 1B 06 03 55 04 0A 13 14 45 78 61 6D 70 1.0...U....Examp
6C 65 20 4F 72 67 61 6E 69 7A 61 74 69 6F 6E 02 le Organization.
04 14 00 00 29 30 0C 06 08 2A 86 48 86 F7 0D 02 ....)0...*.H....
02 05 00 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 ...0...*.H......
05 00 04 40 05 FA 6A 81 2F C7 DF 8B F4 F2 54 25 ...@..j./.....T%
09 E0 3E 84 6E 11 B9 C6 20 BE 20 09 EF B4 40 EF ..>.n... . ...@.
BC C6 69 21 69 94 AC 04 F3 41 B5 7D 05 20 2D 42 ..i!i....A.}. -B
8F B2 A2 7B 5C 77 DF D9 B1 5B FC 3D 55 93 53 50 ...{\w...[.=U.SP
34 10 C1 E1 E1 4....
Many other demo (not only ;) keys, tons of related C++ source/libraries for
Linux and Win32 and documentation can be found on my web site at this address
(case sensitive):
http://members.tripod.com/~xception_0x0A28/penumbra.html
"That which does not kill us
makes us stronger"
-- Friedrich Nietzsche
----[ EOF
