為了滿足緊急狀況，這個方法將所有的私密金鑰一併存放在 TA (Trusted Authority)，以 便緊急狀況時醫生能夠去擷取病人的資料，此舉無疑造成了金鑰集中的安全性問題，TA
9
來做加密，這套系統需要智慧卡來儲存 transaction code (TAC)，如圖 2 所示，加密 EHR 時，病人利用其智慧卡通過 TAC 服務認證取得 TAC，再將 TAC 及 ID 傳送給醫生 1，
醫生 1 產生 EHR 後利用這兩個屬性將 EHR 加密，若醫生 2 想存取病人的 EHR，則需 病人給予 TAC，醫生 2 再依此 TAC 與病人 ID 向 PKG 要求私密金鑰，並以私密金鑰解 密病人的 EHR。但是此系統依賴一個 TAC 服務來產生金鑰，同樣存在金鑰集中的問題，
另一個問題是，EHR 的加密是由醫生執行，病人無法確保醫生在加密時是否會新增存取 規則，使得醫生本身能夠自由存取該 EHR，如此一來病人的隱私便無從保證。
圖 2 Patient-Controlled System
[10][11][12][13][14][15] 皆是以 CP-ABE 為基礎來做資料的存取，儘管在這幾個系 統中，不像[17] 是將加密交由醫生來執行，而是病人自己制定存取規則並加密，但同樣 系統中只有一個屬性授權中心，如圖 3 所示，此授權中心管理所有的屬性，產生公開金 鑰，之後病人再利用這些公開金鑰制定存取規則並上傳到雲端伺服器，而醫生須事先向 授權中心要求私密金鑰方可存取病人之 PHR，[10][11][12][13][14][17] 同樣都將金鑰集 中在一個授權中心之下，將金鑰管理的責任全部交託給一個授權中心管理，無疑讓授權 中心掌握過大的權限，使得他可以任意去存取病人的 PHR，另外一個問題是，負責產生 與管理所有的金鑰對於授權中心而言負載太重。
10
圖 3 使用 CP-ABE 的 PHR 系統架構
[9]的系統則是一個多層的架構，首先利用 KP-ABE，病人將 EHR 以種類作為屬性 來加密，利用 IBE 來傳送 KP-ABE 的金鑰給醫院，保證金鑰傳輸的安全，在醫院之下的 人如醫生、護士等，依其身分使用 CP-ABE 產生私密金鑰，由醫院決定那些身分的人可 以存取 EHR，並定義存取規則使用 CP-ABE 將 KP-ABE 的金鑰加密，簡言之，此系統 裡用 KP-ABE 來分類 EHR，再使用 CP-ABE 來篩選可以存取 EHR 的使用者。如圖 4 所 示。
圖 4 Hierarchical 的 PHR 系統
11
為了解決金鑰集中的問題，[8]首先提出多屬性授權中心的 PHR 存取控制系統，作 者將被授權者分成公開領域與私人領域兩部分，對於公開領域的人是以 MA-ABE 來做 存取控制；私人領域則是以 KP-ABE 來做存取控制，參考圖 5。換句話說，在公開領域 之中，有多個屬性授權中心分別管理一些屬性，這些屬性與身分或職業相關，被授權者 透過請求從授權中心取得私密金鑰，病人利用屬性中心的公開金鑰來加密 PHR，制定存 取規則決定誰可以解密他的 PHR，然而，在他們的系統中，授權中心的數量是固定的，
新的授權中心出現整個系統必須重新設定，使用者所能制定的規則也必須是 CNF，並且 加密時一定要從每一個屬性授權中心至少選擇一個屬性來做加密，使得規則沒有彈性，
被授權者亦必須從所有的授權中心取得金鑰才能滿足存取規則。另外，私人領域的部分 則是運用 KP-ABE，將 PHR 根據其分類的屬性加密，將存取規則定義在被授權者的私密 金鑰上。
圖 5 使用 MA-ABE 的 PHR 系統
…
12
非退化性(Non-Degenerate)：
∃ 𝑃, 𝑄 ∈ 𝐺1, 𝑒(𝑃, 𝑄) ≠ 1
可計算性(Computability)：
∀ 𝑃, 𝑄 ∈ 𝐺1, 𝑒(𝑃, 𝑄)可以有效率地被運算出來。
3.2 存取結構(Access Structure)
Definition 3.2.1 (Access Structure)
令{𝑃1, … , 𝑃𝑛}為一個 party 的集合，假如對 ∀ 𝐵, 𝐶 ∶
3.3 Linear Secret-Sharing Scheme
Definition 3.3.1 (Linear Secret-Sharing Schemes, LSSS)
在一組 party 的集合 𝒫 之下的一個 secret sharing scheme П 如果是線性的，會滿足 以下條件：
1. 每個 party 的 share 集合起來會形成一個在 𝑍𝑝 底下的向量(vector)。