1、網(wǎng)絡(luò)與信息安全安全基礎(chǔ) (四),潘愛民，北京大學(xué)計算機研究所 ,內(nèi)容,SSL/TLS協(xié)議 授權(quán)和訪問控制 安全基礎(chǔ)部分小結(jié),SSL/TLS協(xié)議,1994年Netscape開發(fā)了SSL(Secure Socket Layer)協(xié)議，專門用于保護(hù)Web通訊 版本和歷史 1.0，不成熟 2.0，基本上解決了Web通訊的安全問題 Microsoft公司發(fā)布了PCT(Private Communication Technology)，并在IE中支持 3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷 TLS 1.0(Transport Layer Security, 也被稱為SSL 3.1)，199

2、7年IETF發(fā)布了Draft，同時，Microsoft宣布放棄PCT，與Netscape一起支持TLS 1.0 1999年，發(fā)布RFC 2246(The TLS Protocol v1.0),SSL/TLS協(xié)議,協(xié)議的設(shè)計目標(biāo) 為兩個通訊個體之間提供保密性和完整性(身份認(rèn)證) 互操作性、可擴(kuò)展性、相對效率 協(xié)議的使用,SSL/TLS概況,協(xié)議分為兩層 底層：TLS記錄協(xié)議 上層：TLS握手協(xié)議、TLS密碼變化協(xié)議、TLS警告協(xié)議 TLS記錄協(xié)議 建立在可靠的傳輸協(xié)議(如TCP)之上 它提供連接安全性，有兩個特點 保密性，使用了對稱加密算法 完整性，使用HMAC算法 用來封裝高層的協(xié)議 TLS握

3、手協(xié)議 客戶和服務(wù)器之間相互認(rèn)證 協(xié)商加密算法和密鑰 它提供連接安全性，有三個特點 身份認(rèn)證，至少對一方實現(xiàn)認(rèn)證，也可以是雙向認(rèn)證 協(xié)商得到的共享密鑰是安全的，中間人不能夠知道 協(xié)商過程是可靠的,SSL/TLS協(xié)議棧,為上層協(xié)議提供安全性 保密性 身份認(rèn)證和數(shù)據(jù)完整性,TLS會話,(TLS Session)定義： 指客戶和服務(wù)器之間的一個關(guān)聯(lián)關(guān)系。通過TLS握手協(xié)議創(chuàng)建session，它確定了一組密碼算法的參數(shù)。Session可以被多個連接共享，從而可以避免為每個連接協(xié)商新的安全參數(shù)而帶來 昂貴的開銷。 TLS Session都有一個當(dāng)前狀態(tài) TLS connection 與底層協(xié)議的點對點連

4、接相關(guān)聯(lián) 每個connection都與一個session相關(guān)聯(lián) 連接是短暫的,TLS會話狀態(tài),實際上是一組參數(shù)，包括 Session identifier，字節(jié)序列，由服務(wù)器產(chǎn)生，用來標(biāo)識一個會話狀態(tài) Peer certificate(可以為NULL)，對方的X.509 v3證書 Compression method，壓縮數(shù)據(jù)的算法 Cipher spec，指定數(shù)據(jù)加密算法和用于HMAC的散列算法，以及算法的有關(guān)參數(shù) Master secret, 客戶和服務(wù)器之間共享的48字節(jié)的數(shù)據(jù) Is resumable，標(biāo)記是否這個會話可以被用來初始化一個新的連接,TLS連接的狀態(tài),連接狀態(tài)也包含一組參

5、數(shù) Server and client random，客戶和服務(wù)器為每個連接選擇的字節(jié)序列 Server write MAC secret，服務(wù)器在發(fā)送數(shù)據(jù)的時候，用于MAC運算的key Client write MAC secret ，客戶在發(fā)送數(shù)據(jù)的時候，用于MAC運算的key Server write key，服務(wù)器加密數(shù)據(jù)的密鑰，以及客戶解密數(shù)據(jù)的密鑰 Client write key，客戶加密數(shù)據(jù)的密鑰，以及服務(wù)器解密數(shù)據(jù)的密鑰 Initialization vectors，在CBC模式中用到的IV，最初由握手協(xié)議初始化，以后，每一個記錄的最后一個密文塊被用作下一個記錄的IV Seq

6、uence numbers，每一個連接都需要維護(hù)一個序 列號，當(dāng)密碼參數(shù)變化時，重置為0,TLS記錄協(xié)議TLS Record Protocol,操作過程示意圖,TLS記錄協(xié)議中的操作,第一步，fragmentation 上層消息的數(shù)據(jù)被分片成214字節(jié)大小的塊，或者更小 第二步，compression(可選) 必須是無損壓縮，如果數(shù)據(jù)增加的話，則增加部分的長度不超過1024字節(jié) 第三步，計算消息認(rèn)證碼(MAC) 計算公式：HMAC_hash(MAC_write_secret, seq_num | TLSCompressed.type | TLSCompressed.version | TLSC

7、ompressed.length | TLSCompressed.fragment),TLS記錄協(xié)議中的操作(續(xù)),第四步，encryption 采用CBC，算法由cipher spec指定 數(shù)據(jù)長度不超過214+2048字節(jié)，包括 加密之后的數(shù)據(jù)內(nèi)容 HMAC padding, 共padding_length，每個字節(jié)的值也是padding_length padding_length IV，初始協(xié)商指定，以后，前后記錄連接起來 說明：如果是流密碼算法，則不需要padding,TLS記錄協(xié)議的處理結(jié)果,結(jié)果如下： struct ContentType type; 8位，上層協(xié)議類型 Proto

8、colVersion version; 16位，主次版本 uint16 length; 加密后數(shù)據(jù)的長度， 不超過214+2048字節(jié) EncryptedData fragment; 密文數(shù)據(jù) TLSCiphertext;,length,TLS密碼變化協(xié)議Change Cipher Spec Protocol,它位于TLS記錄協(xié)議之上 所以，它用到了TLS記錄協(xié)議的處理過程 ContentType = 20 協(xié)議只包含一條消息，一個字節(jié) 1 用途：切換狀態(tài)把密碼參數(shù)設(shè)置為當(dāng)前狀態(tài)在握手協(xié)議中，當(dāng)安全參數(shù)協(xié)商一致后，發(fā)送此消息 這條消息使得接收方改變當(dāng)前狀態(tài)讀參數(shù)，使得發(fā)送方改變當(dāng)前狀態(tài)寫參數(shù),

9、TLS警告協(xié)議Alert Protocol,位于TLS記錄協(xié)議之上 所以，也用到了TLS記錄協(xié)議的處理過程 ContentType = 21 協(xié)議數(shù)據(jù)包含兩個字節(jié)第一個字節(jié)為level：分別為warning(1)和fatal(2)兩種情況第二個字節(jié)為情況說明 Fatal類型的alert消息導(dǎo)致連接立即終止，此時，對應(yīng)該會話的其他連接可以繼續(xù)，但是會話標(biāo)識符無效，以免利用此失敗的連接來建立新的連接,Alert Protocol第二字節(jié)說明,close_notify(0), unexpected_message(10), bad_record_mac(20),* decryption_failed

10、(21),* record_overflow(22), * decompression_failure(30),* handshake_failure(40),* bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47),* unknown_ca(48), *,access_denied(49), decode_error(50),* decrypt_error

11、(51), export_restriction(60), * protocol_version(70), * insufficient_security(71), * internal_error(80), * user_canceled(90), # no_renegotiation(100), #,說明：1 * 表示該消息往往是fatal級別 2 # 表示該消息往往是warning級別 3 對于其他的錯誤情況，發(fā)送方可以根據(jù)情況決定是warning還是fatal,對于warning消息，接收方可以自行決定如何處理，如果是fatal消息，則一定要當(dāng)作fatal消息來對待,TLS握手協(xié)議TL

12、S Handshake Protocol,位于TLS記錄協(xié)議之上 也用到了TLS記錄協(xié)議的處理過程 ContentType = 22 協(xié)議格式 用途： 當(dāng)TLS客戶和服務(wù)器開始通訊的時候，它們要通過協(xié)商，在以下信息方面獲得一致:協(xié)議版本、密碼算法、是否認(rèn)證對方、用什么技術(shù)來產(chǎn)生共享秘密數(shù)據(jù)，等等,TLS握手協(xié)議的流程,交換Hello消息，對于算法、交換隨機值等協(xié)商一致 交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的premaster secret 交換證書和相應(yīng)的密 碼信息，以便進(jìn)行身份認(rèn)證 產(chǎn)生master secret 把安全參數(shù)提供給TLS記錄層 檢驗雙方是否已經(jīng)獲得同樣的安全參數(shù),TLS握手協(xié)

13、議使用的消息,第一階段：建立起安全能力屬性,客戶發(fā)送一個client_hello消息，包括以下參數(shù)：版本、隨機數(shù)(32位時間戳+28字節(jié)隨機序列)、會話ID、客戶支持的密碼算法列表(CipherSuite)、客戶支持的壓縮方法列表 然后，客戶等待服務(wù)器的server_hello消息 服務(wù)器發(fā)送server_hello消息，參數(shù)：客戶建議的低版本以及服務(wù)器支持的最高版本、服務(wù)器產(chǎn)生的隨機數(shù)、會話ID、服務(wù)器從客戶建議的密碼算法中挑出一套、服務(wù)器從客戶建議的壓縮方法中挑出一個,關(guān)于會話ID(Session ID),客戶方 客戶指定的會話ID如果不等于0，則表示它希望基于這個會話來更新已有連接的安全

14、參數(shù)，或者創(chuàng)建一個新的連接 如果會話ID等于0，則表示客戶希望在一個新的會話上建立一個新的連接 服務(wù)器 或者同意客戶指定的會話ID，需要檢查cache中的會話狀態(tài) 或者返回一個新的會話ID,CipherSuite,第一個元素指定了密鑰交換的方法，TLS支持以下一些方法： RSA，要求服務(wù)器提供一個RSA證書 DH(Diffie-Hellman)，要求服務(wù)器的證書中包含了由CA簽名的DH公開參數(shù)?？蛻艋蛘咴谧C書中提供DH公開參數(shù)，或者在密鑰 交換消息中提供此參數(shù) EDH(Ephemeral Diffie-Hellman)，產(chǎn)生臨時的密鑰，DH公開參數(shù)由發(fā)送者的私鑰進(jìn)行簽名，接收者用對應(yīng)的公鑰進(jìn)行

15、驗證 匿名的DH，不加認(rèn)證。會受到中間人攻擊 然后，指定以下信息 加密算法，和類型(流還是分組密碼算法) HMAC算法，MD5還是SHA-1 是否可出口 HashSize Key Material IV Size,第二階段：服務(wù)器認(rèn)證和密鑰交換,服務(wù)器發(fā)送自己的證書，消息包含一個X.509證書，或者一條證書鏈 除了匿名DH之外的密鑰交換方法都需要 服務(wù)器發(fā)送server_key_exchange消息 可選的，有些情況下可以不需要。只有當(dāng)服務(wù)器的證書沒有包含必需的數(shù)據(jù)的時候才發(fā)送此消息 消息包含簽名，被簽名的內(nèi)容包括兩個隨機數(shù)以及服務(wù)器參數(shù) 服務(wù)器發(fā)送certificate_request消息

16、非匿名server可以向客戶請求一個證書 包含證書類型和CAs 服務(wù)器發(fā)送server_hello_done, 然后等待應(yīng)答,第三階段：客戶認(rèn)證和密鑰交換,客戶收到server_done消息后，它根據(jù)需要檢查服務(wù)器提供 的證書，并判斷server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個或多個消息給服務(wù)器 如果服務(wù)器請求證書的話，則客戶首先發(fā)送一個certificate消息，若客戶沒有證書，則發(fā)送一個no_certificate警告 然后客戶發(fā)送client_key_exchange消息，消息的內(nèi)容取決于密鑰交換的類型 最后，客戶發(fā)送一個certificate_verify消

17、息，其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值(用master_secret)進(jìn)行簽名,第四階段：結(jié)束,第四階段建立起一個安全的連接 客戶發(fā)送一個change_cipher_spec消息，并且把協(xié)商得到的CipherSuite拷貝到當(dāng)前連接的狀態(tài)之中 然后，客戶用新的算法、密鑰參數(shù)發(fā)送一個finished消息，這條消息可以檢查密鑰交換和認(rèn)證過程是否已經(jīng)成功。其中包括一個校驗值，對所有以來的消息進(jìn)行校驗。 服務(wù)器同樣發(fā)送change_cipher_spec消息和finished消息。 握手過程完成，客戶和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)。,密鑰交換算法,TLS記錄協(xié)議需要：Ciphe

18、rSuite, master secret, and the client and server random values 在hello消息中，交換隨機數(shù)以及各種算法 對于各種密鑰交換算法，從pre_master_secret計算得到master_secret，然后從內(nèi)存中刪除，公式：master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random+ ServerHello.random)0.47* PRF(secret, label, seed)為偽隨機函數(shù) Master_secret總是48字節(jié)長，而pr

19、e_master_secret長度不定，取決于密鑰交換算法 兩類密鑰交換算法： RSA，客戶產(chǎn)生一個48字節(jié)的pre_master_secret，然后通過服務(wù)器的公鑰傳遞給服務(wù)器 Diffie-Hellman，雙方協(xié)商得到的密鑰被用作pre_master_secret,重用一個TLS會話,客戶和服務(wù)器在交換hello消息中，客戶要求重用已有的TLS會話，服務(wù)器同意使用cache中的會話* session id 跳過第二第三階段，直接把TLS會話中的參數(shù)傳遞給TLS記錄層,偽隨機函數(shù)PRF(secret, label, seed),P_hash(secret, seed) = +HMAC_has

20、h(secret, A(1) + seed) +HMAC_hash(secret, A(2) + seed) +HMAC_hash(secret, A(3) + seed) + . 這里A()定義如下： A(0) = seed A(i) = HMAC_hash(secret, A(i-1) 偽隨機函數(shù) PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);這里，S1和S2為secret的各一半，如果secret為奇數(shù)個字節(jié)，則S1和S2共享一個字節(jié),TLS/SSL安全性分析,針對一些常見

21、的攻擊手法 針對密鑰算法的破解 取決于算法的強度，協(xié)商過程 利用明文模式的攻擊 上層協(xié)議中常常有一些固定的模式可以參考，比如http協(xié)議中g(shù)et字節(jié)串 構(gòu)造字典(密文-密鑰對)，查字典 TLS辦法：用長密鑰，使得不可能構(gòu)造這樣的字典 重放攻擊 TLS中的nonce有32字節(jié)(包含時間戳)，可用于避免重放攻擊 會話ID標(biāo)識了一個完整的會話，要重放部分會話需要知道私鑰 中間人攻擊 通過證書來認(rèn)證對方 對于雙方都是匿名的模式，中間人攻擊也是成立的,歷史上針對SSL/TLS的攻擊,PRNG Million-message attack 其它,SSL: PRNG攻擊,Netscape v1.1版本中存在

22、，利用隨機數(shù)發(fā)生器的弱點 先看隨機數(shù)發(fā)生器,global variable seed; RNG_CreateContext() (seconds, microseconds) = time of day; /* Time elapsed since 1970 */ pid = process ID; ppid = parent process ID; a = mklcpr(microseconds); b = mklcpr(pid + seconds + (ppid 1); （待續(xù)）,SSL: PRNG攻擊(續(xù)),種子關(guān)聯(lián)：pid, ppid, seconds, microseconds Se

23、conds往往可以獲得，microseconds未知 如果在目標(biāo)機器上有賬號，則pid和ppid可以獲得 否則，可以尋找pid和ppid的。對于大多數(shù)UNIX平臺，pid+(ppid 12)只有27位,global variable challenge, secret_key; RNG_GenerateRandomBytes() x = MD5(seed); seed = seed + 1; return x; create_key() RNG_CreateContext(); tmp = RNG_GenerateRandomBytes(); tmp = RNG_GenerateRandomB

24、ytes(); challenge = RNG_GenerateRandomBytes(); secret_key = RNG_GenerateRandomBytes();,PRNG的啟示,PRNG并不是SSL協(xié)議本身的缺陷，而是實現(xiàn)上導(dǎo)致的缺陷 隨機數(shù)對于安全協(xié)議或者安全系統(tǒng)的重要性 源碼開放的另一層含義 關(guān)鍵的代碼接受公眾的審視,Reference: Ian Goldberg and David Wagner, “Randomness and the Netscape Browser”, January 1996 Dr. Dobbs Journal,SSL: Million-message

25、 attack,在RSA算法作加密運算的時候，首先對明文消息進(jìn)行編碼，其格式為,假設(shè)密文C，攻擊者可以產(chǎn)生一系列整數(shù)S并計算C = C*(Se) mod n，在解密的時候，每一個C對應(yīng)于一個M。大多數(shù)的M不會滿足上面的格式，但是有2-16的概率會產(chǎn)生這樣的結(jié)果(因為前兩個字節(jié)是確定的)。攻擊者可以找到一系列滿足條件的S，然后推斷出密文C對應(yīng)的明文M。這個過程大約需要220個消息和應(yīng)答。 攻擊實施依賴于 需要一個可以提供解密準(zhǔn)確性判斷的服務(wù)器稱為oracle SSL實現(xiàn)是否能夠精確地告知明文格式不正確？ 只能得到一個消息的明文，無法得到私鑰,MMA的啟示,實現(xiàn)SSL的時候 對待錯誤消息如何響應(yīng)？

26、 Contiune? 會不會招致DOS？ 返回精確的錯誤 充分利用明文模式 隨機數(shù)填充,References 1 RFC 3218 2 Bleichenbacher D. , Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1 in Advances in Cryptology - CRYPTO98, LNCS vol. 1462, pages: 1-12, 1998.,針對SSL的其他攻擊,Export ciphers and distributed cracking 舉例：

27、 40位RC4， downgrade attacks 往SSL的低版本退化 密碼算法的退化,SSL實現(xiàn),OpenSSL, 最新0.9.6c, 實現(xiàn)了SSL(2,3), TLS(1.0) Openssl a command line tool. ssl(3) the OpenSSL SSL/TLS library. crypto(3) the OpenSSL Crypto library. URL: SSLeay .au/ftp/Crypto/ Microsoft Win2k SSL implementatio

28、n,Microsoft IE中SSL/TLS的一個漏洞,IE處理內(nèi)嵌在HTTP頁面中的HTTPS對象存在一個漏洞 它只檢查HTTPS服務(wù)器的證書是否由可信的CA簽名的，而完全忽略該證書是否有適當(dāng)?shù)拿?，以及是否已?jīng)過期。 對于當(dāng)前這個頁面而言，其實并不危險 問題在于 IE會把這個證書緩存起來，并標(biāo)記為可信任的，一直到瀏覽器的會話結(jié)束 這意味著，假如說，IE客戶在訪問一個HTTP頁面時，如果該頁面被插入一個包含指向有問題的SSL server的HTTPS對象(比如說一個image)的話，IE不會警告遇到一個非法的證書，只要這個證書確實是被可信CA簽名的,IE中SSL/TLS的漏洞的情形,假如說中

29、間人在服務(wù)器返回的頁面上加上一句話 HTTPS部分顯示的是一個被偷來的或者過期的的證書，這個證書是有效簽名的，但是IE并不檢查證書中的名字和過期情況 如果客戶通過HTTPS連接到y(tǒng)oursite網(wǎng)站上，IE將認(rèn)為這是可信的站點，而不再進(jìn)一步檢查 參考：ttp:/,Win2k中的SSL,與Kerberos的關(guān)系 Kerberos是服務(wù)器認(rèn)證客戶的身份 SSL的通常用法是客戶認(rèn)證服務(wù)器的身份 如果客戶提供證書，則可以建立雙向認(rèn)證 服務(wù)器認(rèn)證客戶往往用“用戶名+口令”方式 如何與授權(quán)過程結(jié)合起來,授權(quán)(Authorization)和訪問控制,訪問控制定義 資源的所有者或者控制者準(zhǔn)許其他人訪問這種資源

30、，防止未授權(quán)的訪問 對于進(jìn)入系統(tǒng)的控制機制 幾種安全需求(安全服務(wù)) 信息安全的基本定義包括 保密性、完整性、可用性 系統(tǒng)安全 保密性、身份認(rèn)證、訪問控制 訪問控制模型：Reference Monitor 解釋了主體和客體之間實施訪問控制的機制,基本模型：Reference Monitor,Reference Monitor,主體,客體,控制規(guī)則庫,訪問控制策略,在系統(tǒng)安全策略層次上定義授權(quán)，直接通過系統(tǒng)組件實施控制 最終的結(jié)果可以表示成一個訪問矩陣 實際應(yīng)用中較少使用,訪問控制策略(續(xù)),兩種類型 自主式策略(DAC, discretionary access controls) 為特定的用

31、戶提供訪問信息。這種授權(quán)關(guān)系可能會在運行過程中發(fā)生變化，例如，一個主體可以把授權(quán)關(guān)系傳遞給另一個主體。 訪問信息的決定權(quán)在于信息的創(chuàng)建者 強制式策略(MAC, mandatory access controls) 對一個安全區(qū)域的強制式策略被最終的權(quán)威機構(gòu)采用和執(zhí)行，它基于能自動實施的規(guī)則。將主體和客體分為不同的級別 所有對信息的控制權(quán)都由系統(tǒng)管理員來決定 基于角色的訪問控制策略(RBAC, Role Based Access Control),基于身份的策略：基于個人的策略,對于一個目標(biāo)(客體)，用戶(主體)是否具有讀、寫、修改、管理等等的權(quán)限 結(jié)果等價于訪問矩陣的一行(中的一格) 基礎(chǔ)(前

32、提)：一個隱含的、或者顯式的缺省策略 例如，全部權(quán)限否決，在此基礎(chǔ)上定義個人的策略 最小特權(quán)原則：要求一個最大限度地限制每個用戶為實施授權(quán)任務(wù)所需要的許可集合 在不同的環(huán)境下，缺省策略不盡相同，例如，在公開的布告板環(huán)境中，所有用戶都可以得到所有公開的信息 對于特定的用戶，有時候需要提供顯式的否定許可 例如，對于違紀(jì)的內(nèi)部員工，禁止訪問內(nèi)部一些信息,基于身份的策略：基于組的策略,一組用戶對于一個目標(biāo)具有同樣的訪問許可。是基于身份的策略的另一種情形 相當(dāng)于，把訪問矩陣中同一列中多個格壓縮為一格 實際使用時 先定義組的成員 對用戶組授權(quán) 同一個組可以被重復(fù)使用 組的成員可以改變,基于規(guī)則的訪問控制,

33、屬于強制式策略 多級策略 給每個目標(biāo)分配一個密級 密級形成一個層次 每個用戶被分配一個相應(yīng)的級，反映了該用戶的最基礎(chǔ)的可信賴度 兩種訪問控制關(guān)系： 下讀/上寫 保密性上讀/下寫 完整性 這種模型常用于政府機密部門 基于間隔的策略 時間粒度上的控制,基于身份的控制&基于規(guī)則的控制,基于身份的控制 配置的粒度小 配置的工作量大，效率低 基于規(guī)則的控制 配置的粒度大 缺乏靈活性,基于角色的策略,與現(xiàn)代的商業(yè)環(huán)境相結(jié)合的產(chǎn)物 同時具有基于身份策略的特征，也具有基于規(guī)則的策略的特征 可以看作是基于組的策略的變種。根據(jù)用戶所屬的角色作出授權(quán)決定 角色的定義： 每個角色與一組用戶和有關(guān)的動作相互關(guān)聯(lián)，角色中

34、所屬的用戶可以有權(quán)執(zhí)行這些操作 角色與組的區(qū)別 組：一組用戶的集合 角色：一組用戶的集合 + 一組操作權(quán)限的集合,RBAC的優(yōu)勢,增加一層間接性帶來了靈活性 便于管理員賦予最小權(quán)限 便于職責(zé)分擔(dān) 便于目標(biāo)分級 低的管理代價,舉例：COM+中基于角色的控制,其他的訪問控制,與目標(biāo)的內(nèi)容相關(guān)的訪問控制 動態(tài)訪問控制 多用戶訪問控制 當(dāng)多個用戶同時提出請求時，如何做出授權(quán)決定 基于上下文的控制 在做出對一個目標(biāo)的授權(quán)決定時依賴于外界的因素，比如時間、用戶的位置等,目標(biāo)的粒度和策略的結(jié)合,在設(shè)計一個安全系統(tǒng)時，授權(quán)粒度代表了控制的粒度和能力 比如，有的數(shù)據(jù)庫只能控制對一張表的整體訪問或者禁止，而有的可

35、以對一個字段進(jìn)行控制 多種策略的結(jié)合 如何協(xié)調(diào)這些策略 規(guī)定策略的優(yōu)先級 否定策略的優(yōu)先級,訪問控制機制：訪問控制表(ACL, Access Control List),訪問控制列表 對應(yīng)于訪問控制矩陣中的一列內(nèi)容 基于身份的訪問控制策略和基于角色的訪問控制策略都可以用ACL來實現(xiàn) 優(yōu)點： 控制粒度比較小 適用于被區(qū)分的用戶數(shù)比較小的情況，并且這些用戶的授權(quán)情況相對比較穩(wěn)定的情形,其他訪問控制機制,訪問能力表 授權(quán)機構(gòu)針對每個限制區(qū)域，都為用戶維護(hù)它的訪問控制能力 與ACL相比較：在每個受限制的區(qū)域，都維護(hù)一個ACL表 安全標(biāo)簽 發(fā)起請求的時候，附屬一個安全標(biāo)簽，在目標(biāo)的屬性中，也有一個相應(yīng)的

36、安全標(biāo)簽。在做出授權(quán)決定時，目標(biāo)環(huán)境根據(jù)這兩個標(biāo)簽決定是允許還是拒絕訪問 常常用于多級訪問策略 基于口令的機制,一般化的訪問控制機制,對于一個reference monitor訪問控制模型，可以設(shè)想在發(fā)起方(主體)有一些附屬的安全屬性信息，在目標(biāo)方(客體)也有一個附屬的安全屬性信息 授權(quán)機構(gòu)根據(jù)這些信息做出授權(quán)決定,Reference Monitor,主體,客體,控制規(guī)則庫,安全屬性,安全屬性,Windows平臺上有關(guān)訪問控制的幾個概念,SID 是一個可變長度的結(jié)構(gòu)，用來唯一地描述一個用戶或者組 可以轉(zhuǎn)化為字符串形式 SD 包含了與一個安全對象有關(guān)的安全信息 Security identifiers (SIDs) for the owner and primary group of an object DACL(discretionary access-control list) SACL(system access-control list) 以及一組控制標(biāo)記 數(shù)據(jù)結(jié)構(gòu)ACL、ACE Access token 此對象描述了一個進(jìn)程或者線程的安全環(huán)境 包括SID，以及用戶所屬的組的SIDs, logon SID,Windows NT/2000的安全策略,安全基礎(chǔ)部分小結(jié)密碼學(xué)基礎(chǔ),對稱加密算法 DES Feiste