●概述：
來自澳大利亞的軟體社群Legion of the Bouncy Castle Inc，開發充氣城堡(Bouncy Castle)並持續維護，在此非指兒童遊樂設施，而是為C與Java應用程式所設計之加密運算函式庫，支援範圍包括Android，儲存檔案格式稱BKS(Bouncy-Castle KeyStore)，類似Sun或Oracle的JKS keystore，檔案內裝載公鑰、私鑰、憑證，由於Bouncy Castle之金鑰雜湊訊息鑑別碼(HMAC)本應具160 bit長度之hash運算結果，受程式設計錯誤拖累，致使HMAC鍵僅有16 bit，一旦遭受本機暴力破解攻擊，數秒內可猜測其HMAC值而瓦解資料完整性，儘管密鑰與密碼未破解，實際資料內容仍受保護，然不排除BKS V1檔案被詳盡分析，帶來後續攻擊之可能性，此缺陷已被注意6年之久，迄今始正式提出警告，尤其是84%的Android應用程式正使用BKS V1檔案，恐帶來不少衝擊，改良版軟體已公開供應。
●編註：
(1)簡述HMAC
金鑰雜湊訊息鑑別碼(Keyed-hash message authentication code)，縮寫HMAC，係屬經特定運算之訊息鑑別碼(MAC)型態，結合加密hash函數(MD5或SHA-1)與1組密鑰可得該鑑別碼，輸出之HMAC視同訊息摘要，用以檢驗資料完整性與鑑定訊息可靠性。
至於HMAC在驗證身分過程如何發揮作用，略為：
※client送出請求；
※server回傳亂數值R；
※client收到R當作密鑰，與用戶密碼運算，產生金鑰雜湊訊息鑑別碼(HMAC)；
※server用亂數值R，與用戶資料內密碼值運算，得HMAC；
※server比對自行計算之HMAC與client提供之HMAC，相符則判斷用戶合法。
整個驗證流程中可能被攔截之數據即亂數值R與HMAC，單憑二項資料是無法反推真正的用戶密碼，藉此強化安全性。
不過任何雜湊函數演算法皆難免hash collision，只要hash table夠大，碰撞不至於有過分影響，而hash table容量取決於hash值字串長度，例MD5訊息摘要(128 bit)只要1丁點CPU能量即可找到碰撞；SHA-1(160 bit)的碰撞需CPU耗6500年，換成GPU則耗110年；至於SHA-256(256 bit)的確沒有機會碰撞了。
(2)充氣城堡keystore V1弱點
Bouncy Castle第1版BKS，通稱BKS V1，具有hash collision弱點，雖說碰撞是稀鬆平常的現象，但BKS V1囿於HMAC長度過短，無法有效保護資料，先從原始程式觀察其癥結。
hmac_fn = hashlib.sha1
hmac_digest_size = hmac_fn().digest_size
hmac_key_size = hmac_digest_size*8 if version != 1 else hmac_digest_size
hmac_key = rfc7292.derive_key(hmac_fn, rfc7292.PURPOSE_MAC_MATERIAL, store_password, salt, iteration_count, hmac_key_size//8)
在SHA-1演算之條件下，版本為1時，hmac_key_size 等於hmac_digest_size，即160 bit(20 byte)，但於末行hmac_key計算式竟是hmac_key_size//8，20 byte除8去餘數得2 byte，編撰者原意不明，顯然是指令設計錯誤，據計算結果表示hmac索引鍵長度僅2 byte，1串16 bit的鍵值頂多65536種可能性。
故本機端攻擊者，可採用brute-force工具，數秒內破解SHA-1雜湊函數的防禦，找到匹配的HMAC，無論用戶密碼有多麼複雜，可謂BKS V1完整性檢查幾乎不存在，在此強調僅有完整性檢查遭顛覆，但真正的密鑰仍在密碼加密保護下，實際資料內容仍未被取得，只是駭客獲得權限觸及BKS V1檔案，要擔心keystore被分析後，恐衍生進階攻擊。