#依附關係 #依戀關係 #不可思議的機制
#安全堡壘 #回應性 #感受性
.
依附機制其實與我們人類健康及生存息息相關且不可或缺,這點在上世紀末已經闡明,近年更加受到矚目。
.
依附機制一方面與男女交往成家、生育子女有關,一方面則與遠離壓力,順利融入社會有關。換句話說,最近社會上急速增加的虐待問題,以及與憂鬱、壓力相關的障礙問題, 這些都和依附脫離不了關係。
.
第一個注意到依附現象並將其理論化的,是英國發展心理學家約翰.鮑比(John Bowlby)。他剛當上心理醫生不久時,參與了一項針對不良少年實施的臨床研究,調查四十四名犯下竊盜案的少年,結果發現這四十四名少年都有缺乏母愛的問題,於是,鮑比開始將注意力放在個案與母親之間的關係。後來,第二次世界大戰發生,英國遭納粹德國空襲,為避難產生大量「疏散兒童」,鮑比又注意到這些與家人分離的孩子身上出現各種身心問題。大戰結束後,世界衛生組織委託他著手調查戰爭中失去父母的兒童狀況,證實失去母親會對兒童身心造成嚴重傷害。
.
當時的主流精神分析理論更重視子女與父親的關係,認為兒童與母親之間只有哺育照護等功利性的關係,甚至流行一股強調兒童與母親關係過於濃密將有害兒童身心發展的風潮。
.
相較之下,鮑比秉持自己的研究成果,認為與母親之間的連結會對兒童產生更重要的作用。起初他使用「母愛剝奪」(maternal deprivation)一詞,強調孩子與母親之間的連結遭到破壞時會造成負面影響,之後轉而著眼於此一連結帶來的正向效果。他將母親與孩子之間的連結稱為依附(attachment),認為依附機制不只人類,在哺乳類身上也可看見,是一種生物學上的機制。由於重視生物學的一面,依附療法成為與精神分析等心理療法有決定性差異的理論。
.
一九七〇年代前後,鮑伯和他的共同研究者瑪麗.愛因斯沃斯(Mary Ainsworth)幾乎確立了今日為人熟知的依附理論架構。
.
根據他們的依附理論,年幼的孩童與特別關愛這個孩童的養育者(通常是母親)之間,會產生一種名為依附的特殊連結。在此一連結的作用下,幼子產生跟隨在養育者身邊的欲望,養育者也會在與幼子分離時感到不安與警戒,藉此防禦外敵加害幼子。
.
依附機制的作用還不只如此,唯有從安全穩定的依附關係中產生依附連結,孩子才會開始關心外在世界,展開探索行為,進而促進社會性與知性的發展。相反的,沒有安全穩定的依附關係,就會出現在父母的疏忽下分離,必須自己守護自己的孩子,或者孩子反過來無法脫離父母,對探索行為造成妨礙的狀況。
.
除了先進國家,愛因斯沃斯也在烏干達等發展中國家觀察母親與子女的關係。結果,她在建立了安全穩定依附關係的親子身上發現「安全堡壘」的機能,認為孩子是否能獲得安全的依附,取決於母親的反應。
.
依附可大致分為安全型與不安全型兩種。不安全型又可再分成反抗/矛盾型與逃避型、紊亂型。母親與孩子之間的依附屬於哪種類型,明顯表現在母親將孩子一人留下時孩子的反應,以及母親回來後的反應上。
.
◼️擁有安全型依附的孩子,就算母親不在身邊,也只會呈現少許不安,等母親回來後,孩子亦能坦然表達喜悅。
.
◼️相對的,反抗/矛盾型的孩子一看到母親不在就會展現過度不安,母親回來時更無法坦然撒嬌,而是呈現出生氣或拒絕母親擁抱的反應。逃避型的孩子則是無論母親離開或回來都不在乎,注意力只放在自己的遊戲上。
.
◼️至於紊亂型則沒有固定反應,孩子對母親的表情態度非常敏感,配合母親的態度做出反應,不同狀況下甚至可能出現完全相反的反應。有些孩子只要母親一靠近,身體還會瞬間僵硬。這種類型的特徵,是孩子臉上會同時出現渴望關愛與驚慌恐懼的扭曲表情。最典型的例子,就是受虐兒或長期籠罩在父母陰晴不定支配下的孩子。
.
幼兒期的依附類型具有持續性,有七成的人成年後仍維持一歲時的依附穩定性。青年期前確立的依附類型稱為依附形式。成人的依附形式多半可區分為焦慮型(受困型)、逃避型(輕視依附型)、恐懼.逃避型、未解決型等等。焦慮型與逃避型分別相當於幼兒期的反抗/矛盾型及逃避型。恐懼.逃避型則同時具備焦慮型與逃避型的傾向,未解決型則是與父母之間存在依附問題未解決所造成的傷害,也可以說與紊亂型相當接近。
.
另外還有一項重要發現,當他們在追究母親的哪種特性造成依附安全或不安全的差異時,發現答案就在上述愛因斯沃斯提及的「安全堡壘」中。當母親成為孩子稱職的安全堡壘,孩子身上就能培養出安全的依附。
.
更進一步來說,安全堡壘有兩項重要條件,那就是「回應性」與「感受性」。
▫️回應性指的是針對孩子的不同反應做出確實回應,
▫️感受性則是確實感受、讀取孩子的情緒與需求。
▫️可想而知,必須先具備高感受性才有可能達到高回應性。
.
這些發現對精神療法或心理療法的思考具有非常重大的意義,當時卻很少被納入治療第一線,鮑比和愛因斯沃斯也沒能建立一套新的治療理論。他們雖然理解到依附現象真正的重要性,之後又花了很長一段時間,依附理論才實際運用於臨床診斷。
.
「重視與幼兒的互動」這一點,或許很容易和重視幼兒期的精神分析理論混淆。像「三歲兒神話」(譯註:兒童三歲前母親必須專注於育兒,否則會對成長發展有不良影響的說法)至今仍有負面批判,被視為不符科學想像。
.
之所以產生這類誤解,是因為提倡依附理論的,原本都是信奉精神分析的人。因為反對依靠任意解釋,沒有客觀證據理論的精神分析,時代潮流開始轉向基於實證的科學式心理學及精神醫學。帶領這股潮流的,正是行為心理學及精神藥理學。依附理論是立足於生物學基礎上的理論,與精神分析有本質上的差異,即使如此,依附理論依然被視為精神分析的旁枝,曾有一段時期,依附理論隨著精神分析學的衰退遭世人遺忘。
.
#依附理論之復權及推廣展望
.
不過,社會上虐待事件的增加及受虐兒身上明顯可見的依附障礙狀態又逐漸改變了狀況。依附障礙開始被視為一種心理障礙,過去鮑比在戰爭孤兒及疏散兒童身上發現的狀態,也出現在一般家庭之中。
.
比起發展中國家,受虐兒及孤兒身上看見的不安全型依附於近代都市出現的比例更是高得異常。最初發現這一點的就是愛因斯沃斯,她在烏干達研究時只發現極少數例外的逃避型依附個案(這種依附形式的孩子對母親不感興趣或不追求親密感),但研究據點轉移到波士頓後,這種依附形式的個案卻佔了極高比例。這個結果使她感到非常驚訝。
.
此外,根據緬因等人的研究,證實母親的依附類型以極高比例與孩子的依附類型相符。此後,依附不再被視為個人問題,我們開始明白,這是一個橫跨不同世代的連鎖問題。
.
無法從父母身上獲得安全穩定的愛,或是對父母出現不安全型依附的人,往往也無法對自己的小孩產生安全穩定的依附,連帶的,這個小孩也將擁有不安全的依附,這已是經過許多研究證實的事實。
.
依附理論另一個更大的進展是從生物學機制的角度分析依附到分子等級。二十世紀初期,人們發現名為「催產素」的荷爾蒙與授乳及分娩有關。事實上,現在我們知道催產素也支持著親子或夫妻之間的情感連結。
.
此外,進入本世紀後,又發現催產素有著更驚人的作用。包括融入社會、與他人目光相對、產生親密情感、勇於親切助人、寬容原諒、減輕壓力、消除焦慮、鎮定心情、冷靜沉著⋯⋯這些都與催產素的作用相關。催產素從前只被視為與懷孕生產有關的原始荷爾蒙,現在才知道原來還擁有這些促進社會化及共鳴的作用,甚至能發揮抗憂鬱的效果。因此,催產素也被冠上了「#幸福荷爾蒙」、「#愛情荷爾蒙」等稱號。
.
也有報告指出,人們會受幼年時的環境影響,使腦內催產素接收器分佈密度產生變化,導致成年後催產素的作用出現很大差異。這種說法正是從生物學的角度證明了養育環境對人格的影響。
.
如上所述,曾經受到輕視的依附機制,其實是支撐我們生命的根幹,其重要性如今也已再度受到重視。
.
伴隨而來的是嘗試運用依附理論的治療,以英美為中心已逐漸擴展。不過,現狀是多數人仍不明白依附的重要。一如本書即將展開的論述,發揮依附作用的療法將可能超越以往的醫學理論,催生出一個新的治療典範。
.
--
.
📖 https://reurl.cc/3aa3dV
.
本文摘自《依戀,情感關係的溫柔解方:情感支持&建立安全感,超越醫學觀點的復原之路》,作者岡田尊司,日本精神科醫師、作家。京都大學醫學院學士、醫學博士。著有多本心理、精神醫學之大眾書籍。
.
人們的幸福與不幸、成功與失敗、身心健康與否,其實都與「依戀」有關。當醫療觀點束手無策時,站在依戀觀點思考,往往能找到有效改善的做法,尤其對於子女問題、親子關係、夫妻關係等牽涉到親密依附的部分,特別能發揮獨一無二的力量,緩和壓力與創傷的影響,幫助當事者及家人修復僵化的病況與關係,走出傷痛,重建自我。
.
・增加對話、接觸與彼此往來頻率
・開始訴說內心話,願意提及受傷害的心情
・逐漸自省,面對問題,採取改變自我的行動
・從微不足道的成功經驗中,找回自我肯定感
・開始對別人懷抱體貼與感謝之情
・內心建立穩固的安全堡壘
.
知名精神科醫師岡田尊司援引古今,並透過諸多案例探討依戀療法,無論是自身願意透過諮商與練習解決困難,或是想為孩子、親友提供支持,這本書都能給予有力的指引,幫助你超越醫學診斷標籤,積極尋求自救。
人類安全分為哪七項 在 Facebook 的最佳解答
是否有時覺得接電話很煩,寧可傳傳訊息,發發LINE、FB Message、簡訊、What’s APP。寧願不要被打擾,已經是我們現在多數人的生活模式。(本文略長,文末有塵封七年的書寫曝光)
是否覺得很奇怪,為何有人喜歡看別人吃飯直播或是純粹吃飯的畫面。自己用餐的同時,搭配收看他人的吞嚥咀嚼,彷彿我們並非獨自進食。有些人氣高的吃飯直播明星,甚至可以從影片得到贊助獲得六位數的收入進帳(英鎊單位)。
為何有人願意進入直播間打賞?有位易名為Haekjji的吃播明星居然在某場直播受到打賞高達10萬美金?(請見留言處我會貼她的資料)
榮格說:「孤獨並非來自周圍的人沒有陪伴,而是來自不能與人交流自己覺得重要的事,或是觀點不被認可。」
我們現階段處於人類文明發展中的孤獨世紀,跟多年前相比,過去我們要跟他人見面需要等待、寫信、打電話。如今科技發展,我們對互動的模式大相徑庭。過去熱烈擁抱的人際期待,此刻多半處於半閉鎖狀況。
以下節錄、修改自部分《#孤獨世紀》摘要(也是我一個字一個字敲下來的沒有複製貼上喔)。這段應該對於一些喜歡研究數據原理的人有幫助。
大腦的顳頂葉交會區是人的同理心關係最密切的區域,孤獨者對於他人承受苦難時,他們的顳頂葉交會區活躍度下降。非孤獨者的活躍度則上升。
此外,孤獨者會強化「壓力反應」,讓身體整體免疫力承受比他者更大的考驗。這種高度警覺,會讓身體彷彿一台汽車處於一檔階段連續開八小時。
因為孤獨者的心靈,在焦慮與警覺影響下,會以自衛為前提運作。這也是為何芝加哥大學大腦動態實驗室主任史蒂芬尼卡喬波博士說:「在樹林漫步時,孤獨的心靈,隨時都會看到蛇。」
孤獨者的血液中,「正腎上腺素」(Norepinephrine)特別高,這種賀爾蒙在面臨生命威脅時,會關閉防禦病毒的機制。這代表孤獨者處理身體病痛危機時,特別如癌症,他們的免疫系統相對之下減少了很多防護力。
「壓力賀爾蒙」,也就是皮質醇,孤獨者的分泌速度快。相同的,膽固醇上升速度也相對快。就連血壓也是,孤獨者的「杏仁核」,就是大腦裡面處理「戰或逃」的反應,會讓身體感覺危險意識比較久,會導致白血球製造比較多,還會增加發炎反應,綜合上面幾點。
孤獨者的心靈壓力,確實影響了生理健康。
「孤獨」大概是所有藝術創作中的必要之「惡」,因為孤獨,因為孤獨所衍生來的寂寞、心碎、悲憤、怨懟、憤怒、自我懷疑等等,成就了書寫想像上的豐厚羽翼,或是正值青春年華,愛情激發出我們另一個嶄新人格。
然而,無法逃避的是,孤獨確實是當代最明確的顯學。什麼都可能跟孤獨有關,孤獨拓展出新的商機結構。哪怕是單人套餐取代了雙人下午茶,沒有隔間的大格局還比小兩房、三房來得有設計感空間等等。
我們正處在人類有史以來最「孤獨」的時代,想想很諷刺,明明科技讓我們距離縮短了,但人們卻活得比上個世紀中的人們來得不快樂。
工業革命後的財富分配,到2000年、2008年金融海嘯之後,導致巨大傳統產業變化,工時變長,人們疲於應付繁雜行政庶務,自然產生了一層心靈防禦機制。我們被迫要孤獨,尋找不被打擾的節奏,享受一個人的怡然靜心。孤獨,成為當代人的集體約束。
我們某種程度上,被迫孤獨。
《孤獨世紀》這本書的作者是諾瑞娜.赫茲,如果你想了解,想知道更多數據。不管是醫學或是經濟,這位作者的大量田調都能讓你嘆為觀止,原來孤獨並非我們想像那樣而已,孤獨也不是歌詞或是文學的濫觴。
孤獨讓我們身處於數位寂寞泡泡而不自知,未來,2030年之前,全球將有40%的人口是獨居(相當於34億人)。這本書對於某些人來說,也許覺得「大驚小怪」。
孤獨不就那樣嗎?有需要這樣研究嗎?但作者的田野調查很認真,甚至發現孤獨等同每天抽15根菸……此外,孤獨更擴大了民粹主義,讓那些不被瞭解的人,在政治上找到了宣洩之處。
作者也觀察了美國政治上的川普競選活動,找到他當年的競選,確實找出了不少經濟底層的孤獨者。相較之下,我們台灣不也有?
已經好久沒有寫新書分享報告,希望這本書能讓你覺得有興趣想讀讀,從來沒想到孤獨會是這麼大的一個危機啊!
寫到這裡,其實想題外補充一下。
大概是2014年左右,有出版社找我寫關於孤獨的散文集,我也覺得這個寫作文體很有意思,於是開發了「一個人」的系列短文,從一個人的衣櫥、電視、餐具開始書寫起來,寫了大概有十個章節,後來發現寫作過程實在耗掉太多體能,最後只能暫時擱淺。
不過我還是列一下當時書的自序前言給大家看看,免得大家覺得我沒有寫。這也是為何我很想推薦《孤獨世紀》這本書給大家看看,這本書像是當年那本還沒完成的書稿,背後的一份大數據考究資料。
前言
獨自來到,獨自離去。人們多半生存於這世界上都是一個人。一個人是當代經濟顯學,我們越來越習慣一個人,一個人成為多數人的社會縮影進行式。
但是,當一個人面對多數人追求戀愛方程式,或是成家立業的理想勝利組時,彷彿就是既不安全也不適切的代表吧。隨著當代人們情感川流的律動,一個人勢必慢慢取代兩個人,一個人,越能獨處面對寂寞星光,也必能更誠實地面對自己。
本書分為四個選項:分別是溫度、夢遊、西遊與召喚。讓四個選項重新拼湊,並且理解人生。數好了,一二三,開始。
溫度=親密與永恆之間,我們在黑夜持續失溫
一個人的小宅(完成)
一個人的被單(完成)
一個人的燈泡
一個人的時鐘
一個人的沙發(完成)
一個人的餐桌(完成)
一個人的衣櫥(完成)
一個人的鞋盒
一個人的電視
一個人的相框
一個人的日記
夢遊=關於記憶,選擇夢沒有開始的地方
一個人的睡眠
一個人的下午茶
一個人的晨醒咖啡
一個人的失眠
一個人的跨年夜,節慶之後,動物感傷
一個人的性愛是場Epic Love Story
西遊=延冉而上,取經朝貢胃海洋
一個人的菜市場
一個人的Costco,不合時宜
一個人的蛋糕
一個人的套餐
一個人的麻辣火鍋
一個人的集點
一個人的電冰箱
召喚=引力是不變的黏膩,追尋失語者的咒語
一個人的書店(完成)
一個人的KTV
一個人的旅行(完成)
一個人的漫遊
一個人的殘茶
一個人的散步
一個人的馬拉松
一個人的展覽
一個人的電影,不用買一送一
一個人的病床
這是當時書的結構章節,如果你覺得有興趣也歡迎告訴我,或許哪天我就有動力把這本書完成了,那我就會很感謝如今留言的你與妳。
來幫辛苦的出版社工商服務一下。
《孤獨世紀:衝擊全球商業模式,危及生活、工作與健康的疏離浪潮》
商業周刊1739期書摘推薦
誠品選書.香港誠品選書.讀冊選書
圓神書活網 http://bit.ly/P0700151
書展優惠中,推薦搭配桑德爾《成功的迷思》
博客來 http://bit.ly/P0700151-B
誠品 http://bit.ly/3qw5RON
金石堂 https://bit.ly/3s3doEX
讀冊 http://bit.ly/2Nh4BR1
人類安全分為哪七項 在 Taipei Ethereum Meetup Facebook 的最讚貼文
📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Trust Token API 是一個正在標準化的瀏覽器 API,主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能,以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制,而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。
會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私,這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。
問題
大家應該都有點了一個產品的網頁後,很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面,他怎麼會知道我看了這個產品的頁面?
通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。
當使用者登入 Facebook 之後,Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面,當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時,瀏覽器在載入 SDK 時會再度夾帶這個識別碼,此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式,Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡,從你的瀏覽紀錄推敲喜好,餵給你 Facebook 最想給你看的廣告了。
不過跨站追蹤也不是只能用在廣告這樣的應用上,像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。
雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務,但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢?
這就是今天要講的新 API: Trust Token。
Trust Token API - The Chromium Projects
Trust Token / Privacy Pass 簡介
Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制,可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass,所以兩個運作機制類似,但是實作方式稍有不同。
先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春,不過大致上還是可以了解整個概念。
以 hCaptcha 跟 Cloudflare 的應用為例,使用者第一次進到由 Cloudflare 提供服務的網站時,網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。
當使用者答對問題後,Cloudflare 會回傳若干組 blind token,這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token,這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token,在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token,這個步驟稱為 redeem token。
但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起,也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token,但是在後續瀏覽不同網站時把 token 兌換掉時,Clouldflare 並無法區分哪個 token 是來自 Bob,哪個 token 是來自 Alice,但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。
但這樣的機制要怎麼完成呢?以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。
零知識證明 (Zero-knowledge proof)
零知識證明是一種方法在不揭露某個祕密的狀態下,證明他自己知道那個秘密。
Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的,下面簡單的翻譯一下:
假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉,如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力?我們可以設計一個流程來證明這件事情。
Alice 先把眼睛閉起來,請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候,告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到,但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。
而零知識證明的原理大致上就是這樣,你可以用一個流程來證明你知道某個秘密,即使你不真的揭露這個秘密到底是什麼,以上面的例子來說,這個秘密就是超能力運作的方式。
以上就是零知識證明的概念,不過要完成零知識證明有很多各式各樣的方式,今天我們要介紹的是 Trust Token 所使用的零知識證明:DLEQ。
DLEQ (Discrete Logarithm Equivalence Proof)
說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar),如果是大寫如 G, H則是橢圓曲線上面的點 (Point),如果是 vG 則一樣是點,計算方式則是 G 連續相加 v 次,這跟一般的乘法不同,有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。
DLEQ 有一個前提,在系統中的所有人都知道公開的 G 跟 H 兩個點,此時以下等式會成立:
假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何,並且在這個過程中不揭露 s 真正的數值,此時 Victor 可以產生一個隨機數 c 傳送給 Peggy,而 Peggy 則會再產生一個隨機數 v 並且產生 r,並且附上 vG, vH, sG, sH:
r = v - cs
所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值:
vG = rG + c(sG)vH = rH + c(sH)
我們舉第二個等式作為例子化簡:
vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH
這樣只有 Peggy 知道 s 的狀況下才能給出 r,所以這樣就可以證明 Peggy 確實知道 s。
從簡易到實際的情境
Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境,不過前面的例子就會相對比較天真一點,就請大家一步步的往下看。
基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的,以下參與的角色分為 Client 與 Server,並且都會有兩個階段 issue 與 redeem token。
Scenario 1
如果我們要設計一個這樣可以兌換 token 來確認身分的系統,其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server,Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client,這個產生 sT 的過程稱為 Sign Point,不過實際上運作的原理就是橢圓曲線上的連續加法運算。
SignPoint(T, s) => sT
等到 Client 需要兌換時只要把 T 跟 sT 給 Server,Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。
Issue
以下的範例,左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server,反之亦然。
// Client 發送 T 給 Server, 然後得到 sT
T -> <- sT
Redeem
// Client 要 redeem token 時,傳出 T 與 sT
T, sT ->
問題:Linkability
因為 Server 在 issue 的時候已經知道了 T,所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。
Scenario 2
要解決上面的問題,其中一個方法是透過 Blind Signature 達成。Client 不送出 T,而是先透過 BlindPoint 的方式產生 bT 跟 b,接下來再送給 Server bT。Server 收到 bT 之後,同樣的透過 Sign Point 的方式產生結果,不一樣的地方是情境 1 是用 T,而這邊則用 bT 來作 Sign Point,所以得出來的結果是 s(bT)。
Client:BlindPoint(T) => (bT, b)
Server:SignPoint(bT, s) => sbT
而 Blind Signature 跟 Sign Point 具備了交換律的特性,所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind:
UnblindPoint(sbT, b) => sT
這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了,而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點,同時因為 T 從來都沒有送到 Server 過,所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。
Issue
bT -> <- s(bT)
Redeem
T, sT ->
問題:Malleability
以上的流程其實也有另外一個大問題,因為有交換律的關係,當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT):
BlindPoint(sT) => a(sT), a// a(sT) === s(aT)
此時如果將 aT 跟 s(aT) 送給 Server Redeem,此時因為
SignPoint(aT, s) => s(aT)
所以就可以兌換了,這樣造成 Client 可以無限地用任意數值兌換 token。
Scenario 3
這次我們讓 Client 先選擇一個純數 t,並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T,並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。
因為 redeem 要送出的是 t,上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了,因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到,所以就沒辦法無限兌換了。
Issue
T = Hash(t) bT -> <- sbT
Redeem
t, sT ->
問題:Redemption hijacking
在這個例子裏面,Client 其實是沒有必要傳送 sT 的,因為 Server 僅需要 t 就可以計算出 sT,額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題,如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。
不過在網站上沒講出實際上要怎麼利用這個問題,但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好,而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。
Scenario 4
步驟跟前面都一樣,唯一不一樣的地方是 redeem 的時候原本是傳 t, sT,現在則改傳 t, M, HMAC(sT, M),如果再介紹 HMAC 篇幅會太大,這邊就不解釋了,但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。
這樣的特性在這個情境用很適合,因為 Server 透過 t 就可以計算出 sT,透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。
Issue
T = Hash(t) bT -> <- sbT
Redeem
t, M, HMAC(sT, M) ->
問題:Tagging
這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’,這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。
要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。
Scenario 5
前面的 DLEQ 講解有提到,如果有 Peggy 有一個 s 秘密純量,我們可以透過 DLEQ 來證明 Peggy 知道 s,但是又不透漏 s 真正的數值,而在 Privacy Pass 的機制裡面,Server 需要證明自己每次都用 s,但是卻又不用揭露真正的數值。
在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端,但 Server 端的回應就不一樣了,這次 Server 會回傳 sbT 與一個 DLEQ 證明,證明自己正在用同一個 s。
首先根據 DLEQ 的假設,Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client,而 H 則改用 bT 代替。
回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token,所以附上了一個 DLEQ 的證明 r = v - cs,Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替,此時 client 也有 sbT 也就是 sH):
vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT
這樣就可以證明 Server 依然用同一個 s。
Issue
T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)
Redeem
t, M, HMAC(sT, M) ->
問題:only one redemption per issuance
到這邊基本上 Privacy Pass 的原理已經解釋得差不多了,不過這邊有個問題是一次只發一個 token 太少,應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。
Scenario 7
由於一次僅產生一個 redeem token 太沒效率了,如果同時發很多次,每次都產生一個 proof 也不是非常有效率,而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法,這樣就可以大大的降低頻寬需求。
不過這邊我們就不贅述 Batch DLEQ 的原理了,文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。
Issue
T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)
Redeem
t1, M, HMAC(sT1, M) ->
結論
Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式,期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。
不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去,而協議制定的過程中其實廣告龍頭 Google 也參與其中,希望這份協議還是可以保持中立,盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。
參考資料
IETF Privacy Pass docs
Privacy Pass: The Protocol
Privacy Pass: Architectural Framework
Privacy Pass: HTTP API
Cloudflare
Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)
Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化
Other
Privacy Pass official website
Getting started with Trust Tokens (web.dev)
WICG Trust Token API Explainer
Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用,列了很多零知識證明的源碼參考,但可惜的是 DLEQ 這個演算法講解有錯,讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心,源碼應該是可以參考的,解釋的話需要斟酌一下。
關鍵源碼
這邊我貼幾段覺得很有用的源碼。
privacy pass 提供的伺服器端產生 Proof 的源碼
privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼
github dedis/kyber 產生 Proof 的源碼
[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌