home *** CD-ROM | disk | FTP | other *** search
- ---[ 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
-
-