[閒聊] 有沒有憑證都不用檢查的八卦?

看板Soft_Job (軟體人)作者 (鍵盤創業家)時間11年前 (2014/09/30 13:50), 11年前編輯推噓9(9023)
留言32則, 19人參與, 最新討論串1/2 (看更多)
為了怕用市面上的通訊 app 會洩露國家機密,政府好像打算禁用其它通訊軟體 https://www.youtube.com/watch?v=TA5qS8nndr4
除此之外,打算推工研院自己搞的一套 Juiker 號稱資安做得一級棒,身為不務正業的業餘資安人,好奇在網路上找到一份 API 文件, 檔名 "31.Juiker社群通訊服務平台.doc" 看了一下驚為天人,截錄一小段加密方式 http://imgur.com/Vml2psm
"將密文加在Random key後傳送如下" 有沒有好棒棒的政府為了加強資安保密,做出一套好棒棒的系統 產生出來的密鑰是跟密文一起傳送的八卦?金鑰產生的方式就不提了 加密方法用的也是好棒棒被認為已經有問題的 RC4 http://0rz.tw/C2EnG 還有根據官網 https://www.juiker.tw 這套好棒棒好安全的軟體 因為用了 HTTPS 就無敵了,可是 Android client 連憑證都沒驗 http://www.cvedetails.com/cve/CVE-2014-6693/ 有沒有這個國家前途無可限量的感覺? ############### 更新: 根據 FB 上有人的回應是,那份 API 是以前某個活動開放給學生使用的而已 並非真正的產品 API ############### -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 76.21.8.197 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1412056202.A.E04.html

09/30 14:00, , 1F
這個真的不意外,因為政府單位做事情的多數都是一知半解
09/30 14:00, 1F

09/30 14:00, , 2F
,時常文件都寫的很奇特。
09/30 14:00, 2F

09/30 14:54, , 3F
還有可能文件和實作是兩回事
09/30 14:54, 3F

09/30 15:42, , 4F
....這也太厲害
09/30 15:42, 4F

09/30 15:52, , 5F
這樣 Random 的意義是?
09/30 15:52, 5F

09/30 16:17, , 6F
洩漏以後就不算機密了,所以也就沒洩密問題 XD
09/30 16:17, 6F

09/30 16:52, , 7F
我還以為是rsa..base64算那門子密文
09/30 16:52, 7F

09/30 17:08, , 8F
不知道又有幾百萬的稅金收入了
09/30 17:08, 8F

09/30 17:43, , 9F
樓樓上 它是先base64再RC4 雖然還是....
09/30 17:43, 9F

09/30 18:12, , 10F
這api的document寫得好差
09/30 18:12, 10F

09/30 18:15, , 11F
09/30 18:15, 11F

09/30 18:49, , 12F
感覺他得安全性是建立在https之上的
09/30 18:49, 12F

09/30 18:50, , 13F
這一段傳送random key根本多於 要編碼base64就夠了
09/30 18:50, 13F

09/30 19:04, , 14F
可以理解RC4->base64 無法理解base64->RC4 RC4完又爛了吧
09/30 19:04, 14F

09/30 19:06, , 15F
然後HTTPS裡頭用RC4...到底意義是什麼 不相信HTTPS?
09/30 19:06, 15F

09/30 19:52, , 16F
又是圾垃外包 裡面不知道多少回扣 選舉要到了 快找立委
09/30 19:52, 16F

09/30 20:03, , 17F
硬要加密再放KEY該不會是要符合spec吧 還是真的一知半解
09/30 20:03, 17F

09/30 20:13, , 18F
這真的是工研院資通所的團隊自己寫出來的並非外包啊.....
09/30 20:13, 18F

09/30 20:13, , 19F
其它就bj4 XD
09/30 20:13, 19F

09/30 20:50, , 20F
規格並沒有講fixed key對收送雙方如何fixed!沒那麼笨啦!
09/30 20:50, 20F

09/30 20:54, , 21F
別忽略任何國家都要手機通話能被合法監聽,否則就不放照!
09/30 20:54, 21F
它從頭到尾都沒解釋 fixed key 怎麼來的 只說以 ecivreSpiS 做為 fixed key 也沒見到任何 fixed key 的交換機制 那我就只能解讀為 fixed key 就只是做為擴增密鑰長度的一個手段 沒有任何資訊安全的考量在裡面 (當然這手段也是.... 外行囉 正常都用 key derivation function) 好吧 就算他改用其它的字串當 fixed key 問題出在於沒有安全的交換機制 不是走 HTTPS 就叫安全 因為像它最基本的憑證都沒驗 有走等於沒走 如果 fixed key 是跟著手機 app 和各套軟體一起送出來的 那很簡單 我去看一下軟體裡的 fixed key 是什麼就好了 簡單的邏輯推論 沒有交換機制 也只能真的 fixed 要做到國家可以監聽 也不代表也要做到任何阿貓阿狗攔了就可以輕易解開

10/01 00:28, , 22F
一個軟體能不能被合法監聽不是國定機構能管的
10/01 00:28, 22F

10/01 02:24, , 23F
雖然這系統真的滿鳥的
10/01 02:24, 23F

10/01 02:25, , 24F
不過樓主看不出這流程根本是學WEP的也的確很業餘
10/01 02:25, 24F

10/01 02:26, , 25F
通訊軟體用這種方式,最大的洞就是沒有合適方式做key交換
10/01 02:26, 25F

10/01 02:28, , 26F
用hardcode根本是找死
10/01 02:28, 26F
開頭都說了是業餘囉 科科 不過呢 各種 protocol 細節如何的千百種 假如有人的專業是設計 smart card authentication protocol 講究的是用最低耗功去做出安全的協定 (幾乎只用 hash和 xor 避開對稱加解密)之類的 不知道所有東西也是很正常 做研究就是這樣 術業有專攻囉 不過這些並不是我的專業 所以我說我是業餘的 上面有更新寫了 他們說這是以前某次活動設計開放給學生用的 API 並非產品本身的 API 既然他們都這麼講 這部份就沒什麼好說的 只是最基本憑證沒驗還是該打屁股 不過我想了想 還是挺奇怪的 既然是做給學生活動玩的一次性 API 那做那套加密又是為什麼呢? 示範技術? 又或著是?

10/01 02:55, , 27F
我也不太懂做菜,也算業餘的
10/01 02:55, 27F

10/01 02:55, , 28F
但我不會看到廚師加上看不懂的調味料就說 "他要下毒"
10/01 02:55, 28F

10/01 02:57, , 29F
BTW,google一下文件來源就知道,那應該是示範或加題
10/01 02:57, 29F
撇開這 API 的用途不看 這加密確實是有問題阿 你自己也說了 它的 key 是 hardcore 的 再加上 random key 跟著密文一起送 所以這有加密等於沒加密 這應該算常識吧? 應該不用當到特級廚師才能評論這加密有問題吧? 當一道菜有毒 認出它是什麼菜很重要嗎? 你說魔女芝琳的鴉片加在麵裡 或加在飯裡 有差別嗎? 好啦 想想 即然是做給學生玩的 讓學生實作加解密也不錯 這部份沒先查清楚 是我的錯 搶鮮大賽 看來就是他們所說的活動的樣子 http://www.getfresh.org.tw/tdp_detail.aspx?No=62 話說 除了 Android 沒驗 Facebook 上也有人提到 desktop 的 app 也有類似問題的樣子 http://0rz.tw/VbmBJ 去研究實際的 API 呼叫應該會比看那份學生用的 API 文件有趣 有興趣的人再研究看看囉 ※ 編輯: StubbornLin (199.241.202.154), 10/01/2014 04:19:31 ※ 編輯: StubbornLin (199.241.202.154), 10/01/2014 05:16:50 ※ 編輯: StubbornLin (199.241.202.154), 10/01/2014 05:17:20

10/02 15:25, , 30F
那張圖不是Desktop APP, 是Android APP的問題
10/02 15:25, 30F

10/02 15:34, , 31F
最新版App或許有更正了
10/02 15:34, 31F

10/02 15:34, , 32F
有空的人可以測看看
10/02 15:34, 32F
文章代碼(AID): #1KAaIAu4 (Soft_Job)
文章代碼(AID): #1KAaIAu4 (Soft_Job)