というわけで。なんだかんだで、僕の #css2010 は終わりました。

posted at 00:36:03

というわけで， #css2010 にご参加の皆様，お疲れ様でした．次は #scis2011 でお会いできるように頑張ります！

posted at 18:53:24

帰宅なう．ボクにとっての #css2010 は夜の薬をキメるまでです！

posted at 18:45:04

お土産屋さんに、歓迎 #css2010 様ってかいてあった！

posted at 14:09:24

#css2010 だん

posted at 12:08:11

3E2なう。 #css2010

posted at 10:06:11

ホテル最上階バーなう。 #css2010

posted at 22:44:04

エアたますだれwww #css2010

posted at 20:28:50

＼so-kai security／ #css2010

posted at 20:13:41

懇親会なう。 #css2010

posted at 18:45:36

特別講演2なう #css2010

posted at 17:18:27

2F4-3「Webサイトへのマルウェア感染攻撃に関する実態調査」なう #css2010

posted at 15:23:05

2F4-2「異常検知手法を用いたHTML内のスクリプトインジェクション検知」なう #css2010

posted at 14:57:45

BHOを動作させるイベントを入力し．アドウェアの振舞を抽出する解析システム #css2010

posted at 14:40:40

アドウェアが問題になっている #css2010

posted at 14:35:56

2F4-1「ブラウザのアドオンを利用したアドウェアの振る舞い解析」なう #css2010

posted at 14:35:30

2A3だん #css2010

posted at 14:08:29

2F2だん #css2010

posted at 11:47:12

やっぱしSAMLで #css2010

posted at 11:41:49

SSO環境下において各RPが個別IDを持つことはあっても，クレデンシャルは持たないんじゃないかと思うのです． #css2010

posted at 11:40:26

共通IDと個別IDを使って連携する．共通IDと個別IDの紐付けはハンドルで．動きがSAMLっぽい． #css2010

posted at 11:39:25

謝辞：NICTあり！ #css2010

posted at 11:28:51

2F2-5「端末プラットフォーム技術における認証手法」なう #css2010

posted at 11:28:18

Q：OPを統括するOPがいればよいのでは？OP-RPでSSOできるようにOP-OPのSSOができるようになればいいのでは？A：・・・ #css2010

posted at 11:27:12

Q：RP側でローカルのIDとパスワードを持っていることがあると思うが，OP側で対応するのがよいか？同じidentifierを使い続けることに意味があるか．A：IDの統合には意味があると思う．identifierを使い続けることに意味があるかは未検討 #css2010

posted at 11:25:09

Trust FrameworkとRP連結とOP連結の比較：ユーザの煩雑度はRPがダメ．効果の影響と範囲はOP連結が良い．総じて提案方式（OP連結）は良い． #css2010

posted at 11:22:19

（どの程度の間隔で更新すればいいのかってのは問題だよなぁ・・・） #css2010

posted at 11:20:36

そういう情報を付けておくが，正当化情報が古いと情報の信頼性がないので，適宜更新する必要がある．OpenIDの仕組みではユーザを介する必要があるので，OAuthを利用する． #css2010

posted at 11:20:18

OP1の公開鍵を使うので，そのPKCを特定するための情報も準備する．issuer/serialnumber #css2010

posted at 11:19:13

identifierが不正に利用されていないことを示す正当化情報：OP1の公開鍵，identifier1，nonce，OP2のドメイン．などに対して署名する． #css2010

posted at 11:18:36

今回の提案ではOP2がidentifier1とidentifier2の両方を主張して，これらのidentifier所有者が同一であることを証明できるように色々と工夫する． #css2010

posted at 11:17:46

OP1がダメになるとそこが発行するidentifier1が使えなくなるけど，それは困るので，identifier1を異なるOPが正当に主張できるようにする． #css2010

posted at 11:17:02

そこでOP側で解決する方式を提案する． #css2010

posted at 11:16:03

RP側に複数のidentifierを登録すればいいけど，利用するRP毎全部に登録しなくちゃいけないので面倒． #css2010

posted at 11:15:34

シングルサインオンは便利だけど認証サーバが停止するとidentifierが使えなくなるので，今まで使っていたサービス（特にデータ）が利用できない．それは困るので継続利用を考える， #css2010

posted at 11:13:41

2F2-4「OpenIDにおけるID継続の提案」なう #css2010

posted at 11:12:09

2F2-3「OpenIDにおける属性情報の登録と活用に関する提案」だん．tsudaれなかった・・・ #css2010

posted at 11:11:55

登壇なう #css2010

posted at 10:48:40

画象認証 #css2010

posted at 10:41:19

今回の内容なら2週間以内であれば上手く行きそう #css2010

posted at 10:40:13

最後に利用した時間認証：駅や自販機でいつつかったか．（オレの脳味噌じゃ記憶できなさそうorz） #css2010

posted at 10:37:45

利用頻度が低い駅名認証：利用頻度が低い駅はどこか？（1回とか2回のレベルで判断するのは間違えそう） #css2010

posted at 10:36:41

入場した駅認証：最後に入場した駅を答える．（なんとなく常に最寄り駅になりそう・・・通勤にしか使わないオレが悪いのかな？） #css2010

posted at 10:35:46

FeliCaのログを使ったなぞなぞ認証 #css2010

posted at 10:34:06

目的：親しくない人物にFeliCaを盗難された場合，入退室管理システムでなりすましを防ぐ．利便性を低下させない認証． #css2010

posted at 10:33:35

なぜFeliCaか？：かざす理由が必ずある．FeliCa内部にログが残っている．電子チケットの場合は移動履歴が残る． #css2010

posted at 10:32:37

今回はFeliCaに焦点を当てた．iPhone涙目 #css2010

posted at 10:31:19

アクティブな行動：ものを買う，電車に乗る，写真を撮る，などなど #css2010

posted at 10:31:01

思い出せる行動とは何か？：思い出せる行動＝アクティブな行動と定義．印象に残っている行動＞ライフログから #css2010

posted at 10:30:40

位置情報を利用した認証：GPSから得られる位置情報を利用．移動することで自動で更新される．ユーザ自身の行動履歴に基づくので忘れにくいが，全部が思い出せるわけではなかった． #css2010

posted at 10:30:00

2F2-2「FeliCaの利用履歴を用いた個人認証」なう #css2010

posted at 10:27:34

新住基カードはType2に統一．ISO7816-13準拠 #css2010

posted at 10:13:49

2012年に新住基カードの発行（暗号危殆化に対応） #css2010

posted at 10:12:08

想定外に2F2が人いっぱい． #css2010

posted at 10:05:19

2F2-1「公的ICカードを利用した医療機関からの保険資格確認方法の検討」なう #css2010

posted at 10:03:34

全ての参加者が信頼するTTPはムリ＞2者間で同じ事やる #css2010

posted at 09:37:17

じゃんけん！ #css2010

posted at 09:35:33

2D1-4「大規模データベースを扱うプロトコルでの逸脱の防止法」なう #css2010

posted at 09:34:06

Q：情報理論的な証明はあったが，プロトコルの安全性はどうか？A：定義に基づいていれば安全．プロトコルの安全性は暗号学的な安全性にほぼ等価． #css2010

posted at 09:33:50

質疑は聞き漏らした．．． #css2010

posted at 09:30:37

安全性：計算途中結果がわかる場合のエントロピが1.11bitで，漏らさない時は1.65bitで27%の情報漏洩を防いだ #css2010

posted at 09:28:47

まとめ：1.37 #css2010

posted at 09:27:38

数式がいっぱい・・・．要約すると．平均値と類似度がでてくる． #css2010

posted at 09:27:21

提案方式：Step1～4で行う #css2010

posted at 09:24:52

アイデア２：並列処理と逐次処理のハイブリッド方式．乱数を付与しないユーザは並列処理，乱数を付与するユーザは逐次処理．ツリー構成は予めポリシーで． #css2010

posted at 09:22:00

アイデア１：乱数マスキングを用いる．分子と分母の前に同じ乱数マスキングを付けることで，除算するまではランダムな値に見える #css2010

posted at 09:21:02

モチベ２：並列処理で効率的な計算．計算時間をO(n)からO(log n)で可能 #css2010

posted at 09:19:42

評価平均値だけが欲しいのに評価値総和と評価フラグの総和までわかる！ #css2010

posted at 09:19:00

今回のモチベ：余計な情報を漏らしていないか？ #css2010

posted at 09:18:11

準同型性暗号：拡張エルガマル暗号，Paillier暗号などなど． #css2010

posted at 09:17:41

多田菊池09は準同型性暗号を使って効率的だよ！ #css2010

posted at 09:15:09

プライバシ保護協調フィルタリング：プライバシ保護しながら推薦値を計算．Canny02は画期的だったが行列計算が逐次的で効率的じゃない． #css2010

posted at 09:14:46

巨大なデータベースから効率的に情報を取り出す． #css2010

posted at 09:13:47

2D1-3「プライバシ保護情報推薦システムにおける中間情報の秘匿について」なう #css2010

posted at 09:12:53

Q：赤と緑は失効ユーザ数に依存しないと思うが，グラフ化した意味は？A：依存しないわけではない．失効リストが含まれているので，通信時間に影響がある．認証時間に対しては軽微であることを示している． #css2010

posted at 09:11:47

Q：青い線は提案方式とは関係ないと思うがどうか？A：従来方式との比較であり，従来方式と大差なく実装できたことを示している． #css2010

posted at 09:10:41

Q：大学などでの利用だと，定期的に大量にユーザが入れ替わる．今回の方式では失効ユーザ数に比例しているが上手い方法はないか？A：参考文献[2]が参考になると思う．ユーザに負担を強いる方式でありトレードオフがある．ケースバイケースで切替えられると良いと思う． #css2010

posted at 09:09:30

グループ署名の検証時間が失効ユーザ数に比例している #css2010

posted at 09:06:58

グループ識別プロトコル追加によるオーパヘッドは0.2秒．検証情報取得は0.01秒． #css2010

posted at 09:06:33

X.509準拠で #css2010

posted at 09:02:09

従来プロトコルの問題点：単一組織での利用を想定．複数組織間の認証はできない．＞無線LANではローミングとか大事． #css2010

posted at 08:56:27

グループ署名：匿名性のあるディジタル署名技術 #css2010

posted at 08:54:41

認証サーバにユーザのプライバシが残るのが問題だ．それをなんとかする． #css2010

posted at 08:54:19

無線LAN接続時の認証セキュリティが大事．IEEE802.1X！ｴｰｰｰｯｸｽ！！（最後のはtsuda者のノリです） #css2010

posted at 08:53:39

2D1-2「組織間連携を考慮した匿名IEEE802.1X認証プロトコルの実装」なう #css2010

posted at 08:52:05

Q：KGCはどのくらいあるか？A：あんまない．アメリカにはボネらの会社があるらしい． #css2010

posted at 08:51:38

Q：KGCの実装をもう少しｋｗｓｋ！A：PBCを使っているので実装速度優先でC言語で書いた．中身はApacheでインタフェイスを拡張している． #css2010

posted at 08:51:06

コメント：証明書が無くなることによって利用者にデメリットが生じることもあると思うので，ブレークスルーになるかもしれない． #css2010

posted at 08:49:14

Q：フィッシングはどうか？A：フィッシング対策は今回の視野外．別途検討が必要．KGCはIDに対する保証が主なので． #css2010

posted at 08:48:27

Q：IBEのメリットは？A：公開鍵証明書が不要． #css2010

posted at 08:47:31

ざわざわ… RT @zusanzusan: #css2010 座長がいないセッションがあるらしい...CSS 2010 のしおりの最終ページを使うときが！

posted at 08:41:06

PBCとGMPでやるよ！（順当） #css2010

posted at 08:36:36

RFC準拠のIBEなOpenSSLの実装．そｒが使えるApacheの実装．・・・． #css2010

posted at 08:36:12

RFC5091とRFC5408がIBE実装のRFCサポートである #css2010

posted at 08:35:06

IBEは公開鍵暗号化方式の一種．公開鍵としてID情報を利用可能．公開鍵証明書を必要としない．KGCが必要． #css2010

posted at 08:33:33

ハイブリッド暗号の公開鍵による鍵交換部分についてIBE使えないかなぁがモチベ #css2010

posted at 08:32:50

OpenSSL/Apacheを拡張してKGC実装する #css2010

posted at 08:31:40

2D1-1「RFCに準拠したIDベース暗号のTLS適用とOpenSSL, Apache HTTP Serverへの実装」なう #css2010

posted at 08:30:59

2D1は座長独唱なし #css2010

posted at 08:30:57

2D1にきたよ #css2010

posted at 08:27:18

http://www.youtube.com/watch?v=N_H3I1ilgUs #css2010

posted at 00:24:14