基於屬性的加密 (ABE) 中的屬性認證
當數據使用者需要訪問時，它會要求密鑰頒發者使用指定的屬性為其生成密鑰。
密鑰頒發者如何驗證數據使用者實際上獲得了它聲稱擁有的屬性？
如果您查看KP-ABE 論文或第一篇提出 ABE 概念的論文，您會發現一個人聲稱擁有的一組屬性沒有經過身份驗證。
實際上，有一個設置階段，在此階段，人們將獲取想要公開披露的屬性，並生成一個離散的對數公鑰，也就是說，對於每個屬性和一個密鑰生成階段，在此期間相同的“權限”將為每個屬性生成私鑰。
然後可以發布一組屬性，“一組屬性的公鑰”，以及一個隨機選擇的整數 $ y $ . 然後，任何願意這樣做的人都可以使用這些公開披露的密鑰來加密這些屬性子集的數據。
現在，ABE 的神奇之處在於，當您決定對給定的屬性子集進行加密時，只有擁有所有相應屬性的私鑰（由“權威”在密鑰生成階段生成）的人才能組合該子集密鑰以解密該密文。
擁有所有這些屬性的私鑰的人可以執行所謂的解密階段，該階段將雙線性映射 $ e $ 僅當密文被定址到一個人可能擁有的所有屬性密鑰中的給定屬性子集時，才用於“縫合”明文。
然而，將在“設置”期間創建的屬性及其對應的私鑰分配給個人以供他們執行“密鑰生成”的方式，並沒有被方案本身考慮在內，顯然應該以一種安全、經過身份驗證的方式來處理適合每個人的屬性。
因此，生成公鑰和私鑰的“權威”必須有效地將屬性的私鑰分配給“擁有”這些屬性的人，但是 ABE 方案本身並沒有考慮到問題的這個實際方面。
我假設 CP-ABE，因為它更容易理解，但這也同樣適用於 KP-ABE。
幾乎沒有基於屬性的加密方案討論如何在現實世界中使用它。我們可以從傳遞給四種算法的資訊中推斷出它是如何使用的：設置、密鑰生成、加密、解密。
安裝程序採用其他任何地方都沒有提到的安全參數，並輸出一個公鑰和一個主密鑰。主密鑰在 keygen 期間使用，這意味著 keygen 必須由某種中央機構執行。
如果有人可以向中央權威機構查詢一些具有他們選擇的屬性的密鑰，那麼整個系統將被嚴重破壞。這就是你要問的。唯一的答案可能是使用者實際上並沒有能力決定他們擁有哪些屬性。
中央權威可以被建模為具有使用者和一些管理員數據庫的伺服器。管理員將特定屬性分配給特定使用者。在企業的情況下，使用者要麼必須事先註冊，要麼可以從中央身份管理系統獲得。使用者完全有可能在註冊或後續請求期間列出他們想要擁有的屬性，但管理員（或他們委派此權限的其他使用者）必須查看這些請求的屬性並評估它們是否對該使用者有意義。在一個使用者比網際網路上通過某些（垃圾）郵件地址知道的匿名使用者更知名的企業中，這個過程要容易得多。
中央授權伺服器上使用者的實際聯網身份驗證可以是您能想到的任何內容：電子郵件+密碼、多因素身份驗證、OAuth、OpenID Connect、ADFS、SAML、LDAP、Kerberos、RADIUS、IEEE 802.1X 等。 （非常狂野的一堆，僅用於說明目的）
使用者必須成功地通過中央權威認證自己，並且管理員必須授權已知使用者具有特定屬性。這本質上是數據庫中的一個映射表。使用者認證後，他們可以向中央機構請求他們的實際密鑰，中央機構從數據庫中查找所有映射並建構包含所有授權屬性的使用者私鑰。
現在ABE的效率理論上來了：加密使用者和解密使用者不需要聯繫中央機構，因為實際的數據授權機制委託給了ABE的密碼學。在實踐中，他們仍然需要定期聯繫中央機構，以防他們認為管理員為他們分配了更多的屬性。
這就是為什麼 ABE 沒有廣泛流行的原因（至少就我嘗試使用 ABE 2 年而言）。
我必須說，我所知道的唯一一個與微不足道的系統相比具有一些額外好處的系統在這篇碩士論文中有所描述：TR van de Kamp的將 ABCs 與 ABE 相結合。它將中央機構的屬性授權委託給不同的實體（該實體也有分配屬性的管理員）。
不要誤會我的意思，有許多非常有趣的方案具有各種有趣的功能，但是當您真正考慮在現實世界中使用它時，這些案例似乎非常做作。