pkcs #11

pkcs #11

PKCS#11標準定義了與密碼令牌(如硬體安全模組(HSM)和智慧卡)的獨立於平台的API,並將API本身命名為“Cryptoki”(來自“加密令牌接口”,發音為“crypto-key” - 但是“PKCS#11”通常用於指代API以及定義它的標準)。 API定義了最常用的加密對像類型(RSA密鑰,X.509證書,DES / 三重DES密鑰等)以及使用,創建/生成,修改和刪除這些對象所需的所有功能。

基本介紹

  • 中文名:pkcs #11
  • 外文名:PKCS#11
  • 套用範圍:智慧卡和HSM
  • 別名:Cryptoki
  • 含義:定義了獨立於技術的程式設計接口
  • 學科:密碼學
簡介,適用範圍,套用,關係KMIP,

簡介

在密碼系統中,PKCS#11是公鑰加密標準(PKCS, Public-Key Cryptography Standards)中的一份子 ,由RSA實驗室(RSA Laboratories)發布[1],它為加密令牌定義了一組平台無關的API ,如硬體安全模組和智慧卡。
由於沒有一個真正的標準加密令牌,這個API已經發展成為一個通用的加密令牌的抽象層。 PKCS#11 API定義最常用的加密對象類型( RSA密鑰,X.509證書,DES /三重DES密鑰等)和所有需要使用的功能,創建/生成,修改和刪除這些對象。注意:pkcs#11隻提供了接口的定義, 不包括接口的實現,一般接口的實現是由設備提供商提供的,如usbkey的生產廠商會提供 符合PKCS#11接口標準的API的實現。這樣你只要通過接口調用API函式即可實現其功能。

適用範圍

本標準為那些保存密碼信息,執行密碼函式的設備確定一種程式設計接口(API),該接口稱做Cryptoki。Cryptoki發“Crypto-Key”音,是cryptographic token interface (密碼令牌接口)的縮寫,它遵循一種基於對象的簡單方法,提出技術獨立性(各種各樣的設備)和資源共享(多個應用程式訪問多個設備)的目標,把設備的一種通用的邏輯視圖,即密碼令牌,提供給應用程式。
本文檔通過使用ANSI C程式語言確定適用於需要密碼服務的應用程式的數據類型和函式。這些數據類型和函式將由Cryptoki庫的供應者通過C字頭文檔提供。Cryptoki的通用ANSI C字頭檔案可在PKCS網頁上得到。該文檔和Crypto的最新勘誤表都可在同一地方得到。
附加文檔可提供一個通用的語言獨立的Cryptoki界面和/或Cryptoki與其它程式設計語言間的聯編。
Cryptoki 把套用從密碼設備的詳細資訊中隔離出來。應用程式不必轉換成另一種不同設備的接口或在不同環境下運行,因此,應用程式是很輕便的。Cryptoki怎樣提供這種隔離超出了本文檔的描述範圍,儘管在這裡和可能在其他文檔中找到某些支持多種設備的協定。
本版本支持許多密碼機制。除此之外,新機制能在不改變通用界面的情況下添加進來。可能其它的機制會在不同的文檔中發表,也有可能令牌的提供者確定他們自己的機制(即使由於相互合作、通過PKCS處理的註冊更可取的緣故)。
Cryptoki 2.1版本用來連線單個用戶的密碼設備,所以省略了某些通用目的界面中的特點。例如,Cryptoki 2.1 版本沒有區別眾多用戶的方式。重點在單個用戶的密鑰以及可能與這些密鑰相關的證書。況且,重點在加密上。當設備執行有用的非加密函式時,這些函式放到了其它界面上。

套用

PKCS#11主要是套用於智慧卡和HSM 。大多數商業證書頒發機構軟體使用PKCS#11訪問CA的簽名密鑰或註冊用戶證書。跨平台的軟體需要使用的PKCS #11的智慧卡,如Mozilla Firefox和OpenSSL (擴展使用) PKCS#11 。為微軟Windows編寫的軟體或許會用特定平台的MS-CAPI API來取代
Cryptoki 為一個或多個密碼設備提供一個接口,這些設備通過大量的槽在系統中運行。每個對應於一個物理閱讀器或另一個設備接口的槽可包含一個令牌。當一台密碼設備存在於閱讀器中,一個令牌就存在於該槽中。當然,由於Cryptoki提供槽和令牌的邏輯視圖,所以可能有其它的物理解碼。多個槽可能共享一個閱讀器。問題在於一個系統有相當多的槽,應用程式能連線到這些槽的其中任何一個或全部槽的令牌上。
密碼設備可以按照某一命令集執行某些密碼操作,這些命令通常要經過標準設備驅動程式,例如PCMCIA卡服務程式或槽服務程式。Cryptoki使每個密碼設備看起來邏輯上很象其它設備,而不管什麼技術實現的。因此,應用程式不必直接與設備驅動器接口(或甚至不必知道包括那些設備);Cryptoki 隱藏了這些細節。的確,基礎設備完全能用軟體來實現,(例如,在一個伺服器上運行的處理程式),不須專用硬體
Cryptoki 或許可以作為支持接口功能的庫來實現,而應用程式則與該庫連線。應用程式可以直接與Cryptoki 連線,或者,Cryptoki 是一個所謂的“共享”庫(或動態連線庫),在這種情況下,應用程式動態地連線庫。用Microsoft Windows和OS/2作業系統可以比較容易地生成資料庫,並且在UNIX和DOS中也可相對容易地生成“共享”庫。
由於新庫可以使用,所以動態方法有許多優點;但從安全的角度來說,也有一些缺點。要特別指出的是,如果庫能較容易地被替換,攻擊者有可能用惡意製造的假庫取而代之,以截取用戶的PIN。即使編碼簽名技術能防止許多動態連線的安全危險,從安全形度來說,一般採用直接連線。總之,應用程式和Cryptoki 庫之間的程式設計接口是相同的。
設備的種類和所支持的能力的種類將取決於專用Cryptoki 庫。本標準只定義庫的接口,不定義庫的特徵。要特別指出的是,並不是所有的庫支持這個接口(因為不是所有的令牌支持所有的機制)中定義的機制(算法)。並且庫也許只支持可使用的所有密碼設備的一個子集。(當然,可以預料更多更好的設備種類將被開發,以支持多種令牌,而不是單個供應商提供的令牌。)只要開發出應用程式,就會形成Cryptoki 的接口、標準資料庫和令牌“輪廓”(profile)。

關係KMIP

該密鑰管理互操作協定(KMIP)定義了具有類似的功能的PKCS#11 API一個有線協定。這兩個標準最初是獨立開發的,但現在由OASIS技術委員會管理。PKCS#11和KMIP委員會的明確目標是在切實可行的情況下對準標準。例如,PKCS#11敏感和可提取屬性正在添加到KMIP 1.4版本中。兩個技術委員會成員之間有相當大的重疊。

相關詞條

熱門詞條

聯絡我們