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

[StubbornLin (鍵盤創業家)]

為了怕用市面上的通訊 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
→ jk47tai: 這個真的不意外，因為政府單位做事情的多數都是一知半解
→ jk47tai: ，時常文件都寫的很奇特。
推 ccpz: 還有可能文件和實作是兩回事
推 lamontlui: ....這也太厲害
推 ROCKandROLL: 這樣 Random 的意義是?
→ yr: 洩漏以後就不算機密了，所以也就沒洩密問題 XD
→ felixgugu: 我還以為是rsa..base64算那門子密文
→ juriolegend: 不知道又有幾百萬的稅金收入了
推 mrbigmouth: 樓樓上  它是先base64再RC4  雖然還是....
→ alog: 這api的document寫得好差
→ Obb: http://www.ithome.com.tw/node/83924   大廠都不用RC4了
推 joybee: 感覺他得安全性是建立在https之上的
→ joybee: 這一段傳送random key根本多於 要編碼base64就夠了
推 noonOut: 可以理解RC4->base64 無法理解base64->RC4 RC4完又爛了吧
→ noonOut: 然後HTTPS裡頭用RC4...到底意義是什麼 不相信HTTPS？
→ robler: 又是圾垃外包 裡面不知道多少回扣 選舉要到了 快找立委
→ siriusu: 硬要加密再放KEY該不會是要符合spec吧 還是真的一知半解
推 cpper: 這真的是工研院資通所的團隊自己寫出來的並非外包啊.....
→ cpper: 其它就bj4 XD
推 ggg12345: 規格並沒有講fixed key對收送雙方如何fixed!沒那麼笨啦!
→ ggg12345: 別忽略任何國家都要手機通話能被合法監聽,否則就不放照!
它從頭到尾都沒解釋 fixed key 怎麼來的 只說以 ecivreSpiS 做為 fixed key
也沒見到任何 fixed key 的交換機制 那我就只能解讀為 fixed key
就只是做為擴增密鑰長度的一個手段 沒有任何資訊安全的考量在裡面
(當然這手段也是.... 外行囉 正常都用 key derivation function)

好吧 就算他改用其它的字串當 fixed key 問題出在於沒有安全的交換機制
不是走 HTTPS 就叫安全 因為像它最基本的憑證都沒驗 有走等於沒走
如果 fixed key 是跟著手機 app 和各套軟體一起送出來的
那很簡單 我去看一下軟體裡的 fixed key 是什麼就好了
簡單的邏輯推論 沒有交換機制 也只能真的 fixed

要做到國家可以監聽 也不代表也要做到任何阿貓阿狗攔了就可以輕易解開
推 asdfghjklasd: 一個軟體能不能被合法監聽不是國定機構能管的
→ drinker: 雖然這系統真的滿鳥的
→ drinker: 不過樓主看不出這流程根本是學WEP的也的確很業餘
→ drinker: 通訊軟體用這種方式，最大的洞就是沒有合適方式做key交換
→ drinker: 用hardcode根本是找死
開頭都說了是業餘囉 科科 不過呢 各種 protocol 細節如何的千百種
假如有人的專業是設計 smart card authentication protocol
講究的是用最低耗功去做出安全的協定 (幾乎只用 hash和 xor 避開對稱加解密)之類的
不知道所有東西也是很正常 做研究就是這樣 術業有專攻囉
不過這些並不是我的專業 所以我說我是業餘的

上面有更新寫了 他們說這是以前某次活動設計開放給學生用的 API
並非產品本身的 API 既然他們都這麼講 這部份就沒什麼好說的
只是最基本憑證沒驗還是該打屁股

不過我想了想 還是挺奇怪的 既然是做給學生活動玩的一次性 API
那做那套加密又是為什麼呢？ 示範技術? 又或著是?
→ drinker: 我也不太懂做菜，也算業餘的
→ drinker: 但我不會看到廚師加上看不懂的調味料就說 "他要下毒"
→ drinker: BTW,google一下文件來源就知道，那應該是示範或加題
撇開這 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
→ dingyuchi: 那張圖不是Desktop APP, 是Android APP的問題
→ dingyuchi: 最新版App或許有更正了
→ dingyuchi: 有空的人可以測看看