DigitalTrustInteroperabilityLab

Architecture Overview

Design Philosophy

Digital Trust Interoperability Lab is built on five principles:

  1. Vendor Neutrality — no proprietary code, no vendor-specific hard-coding
  2. Layer Isolation — each cryptographic layer is tested independently
  3. Local-Only — zero network transmission of any cryptographic material
  4. Standards Compliance — all operations use published open standards
  5. Actionable Output — every finding includes root cause + remediation

System Overview

The application is a Windows MFC dialog-based desktop tool that performs comprehensive diagnostics across multiple layers of the PKI stack.

Component Architecture

Layer 1: User Interface (UI)

Files: DiagnosticView.cpp, DigitalTrustLabDlg.cpp

Layer 2: Business Logic (Engines)

Diagnostic Engine

File: Core/DiagnosticEngine.cpp

Orchestrates system, provider, and certificate diagnostics.

Coordinates:

Signature Engine

File: Signature/SignatureEngine.cpp

Multi-provider signature generation:

Signature Verifier

File: Signature/SignatureVerifier.cpp

Cryptographic verification with certificate chain building.

PKCS#11 Loader

File: PKCS11/PKCS11Loader.cpp

Dynamic PKCS#11 DLL loading and testing:

Layer 3: Windows Crypto Abstractions

CryptoAPI Adapter

File: Providers/CryptoAPIAdapter.cpp

CNG Adapter

File: Providers/CNGAdapter.cpp

Certificate Manager

File: Certificate/CertificateManager.cpp

Layer 4: Windows Native APIs

Layer 5: Providers and Hardware

Data Flow

Diagnostic Flow

User clicks [Run All Diagnostics]
    |
    v
DiagnosticEngine.RunAll()
    |
    +--> SystemInfo.Collect()
    +--> CryptoAPIAdapter.EnumerateProviders()
    +--> CNGAdapter.EnumerateProviders()
    +--> CertificateManager.EnumerateStores()
    |
    v
Results aggregated in DiagnosticResultSet
    |
    v
UI updated via PostMessage(WM_DIAG_COMPLETE)
    |
    v
Dashboard, System Info, Providers, Certificates tabs populated

Signature Flow (CryptoAPI Path)

User clicks [Sign]
    |
    v
SignatureEngine.SignFile()
    |
    +--> Find certificate in store
    +--> CertGetCertificateContextProperty (get provider info)
    +--> CryptAcquireCertificatePrivateKey
    +--> CryptCreateHash + CryptHashData
    |       OR (for legacy CSP)
    |    Compute hash externally, then HP_HASHVAL inject
    +--> CryptSignHash (with PIN prompt from provider)
    +--> Reverse bytes (little-endian to big-endian)
    |
    v
Signature stored in SignatureResult
    |
    v
UI updated: Signature History + Result panel

Signature Flow (PKCS#11 Path)

User clicks [Sign via PKCS#11]
    |
    v
Custom PIN dialog (in-memory template)
    |
    v
Background thread starts:
    |
    +--> PKCS11Loader.EnsureInitialized()
    |       (reload DLL if needed for vendor state recovery)
    +--> C_Login with PIN
    |       (PIN SecureZeroMemory'd after use)
    +--> FindFirstSigningKey()
    +--> Read file into memory
    +--> Compute SHA-256 hash externally
    +--> Build ASN.1 DigestInfo + Hash
    +--> C_SignInit + C_Sign (CKM_RSA_PKCS)
    +--> C_Logout
    |
    v
Signature stored in SignatureResult
    |
    v
UI updated

Cross-Path Comparison

Both signatures should be byte-identical for RSA-PKCS#1 v1.5 signing with the same key, file, and hash algorithm. This is proven empirically in the tool’s output.

Thread Safety

Memory Safety

Error Handling

Vendor-Neutral Design Details

PKCS#11 Loader

Uses direct GetProcAddress instead of CK_FUNCTION_LIST struct to avoid layout compatibility issues with vendor DLLs.

This approach was chosen after crash reports from certain vendor DLLs that use non-standard struct layouts.

Provider Detection

Never hard-codes vendor names. All provider identification is runtime-discovered from:

Certificate Store

Uses only standard Windows certificate store APIs. No registry hacks, no undocumented APIs.

Build Configuration

Setting Value
Compiler Visual C++ 2008 (VS 2008 SP1)
Framework MFC (statically linked)
Target Win32 (x86)
CRT Multi-threaded static (/MT for Release)
Character Set Unicode (UTF-16 internal)
Optimization /O2 for Release
Debug info /Zi (both Debug and Release)

Distribution Model

Extension Points

The architecture supports future extensions:

  1. Additional adapters — add new provider types
  2. Additional test cases — extend PKCS#11 test suite
  3. Additional report formats — JSON, XML, PDF
  4. Additional standards — TSP, OCSP live testing
  5. Cross-machine mode — export/import diagnostics

Summary Diagram

+----------------------------------------------------------+
|                    USER INTERFACE (MFC)                  |
|  Dashboard | System | Providers | Certs | PKCS11 | Sign  |
+----------------------+-----------------------------------+
                       |
     +-----------------+-------------------+
     |                 |                   |
     v                 v                   v
+---------+     +-------------+      +-----------+
|Diagnos. |     |  Signature  |      |  PKCS#11  |
| Engine  |     |   Engine    |      |   Loader  |
+----+----+     +------+------+      +-----+-----+
     |                 |                   |
     v                 v                   v
+----------------------------+     +--------------+
| Windows CryptoAPI + CNG    |     | Vendor DLLs  |
| (Vendor-Neutral Layer)     |     +--------------+
+----+---------------+-------+            |
     |               |                    |
     v               v                    v
+---------+     +---------+          +---------+
| Legacy  |     |  CNG    |          | PKCS#11 |
|  CSPs   |     |  KSPs   |          | Vendor  |
+----+----+     +----+----+          +----+----+
     |               |                    |
     +---------------+--------------------+
                     |
                     v
        +--------------------------+
        |   HARDWARE TOKENS        |
        |   Smart Cards, USB, HSM  |
        +--------------------------+

Digital Trust Interoperability Lab — Vendor-Neutral by Design

This site is open source. Improve this page.