SCIS2012 第3日目のまとめ #scis2012

DRokuboX @drokubo

本来は相互認証が単純解だが、一方向通信であるプッシュ通信では困難。 そこで、相互信頼! #3D1 #scis2012

たま＠なら @tama_nara

事務局で着替えていたが、はじまったw 3E1-1 CBCは悪者なのか…。#scis2012 #TwitPict http://t.co/Ko0g5Tmc

拡大

DRokuboX @drokubo

相互信頼機能アプリの実装では？プッシュ型通信と対応アプリの中間に位置する。(相互信頼機能アプリって信頼していいの？) #3D1 #scis2012

Masaki SHIMAOKA @4ma_

あれ、発表者変更ですか(棒読み RT @tama_nara: 事務局で着替えていたが、はじまったw 3E1-1 CBCは悪者なのか…。#scis2012 #TwitPict http://t.co/UEjbfxua

拡大

DRokuboX @drokubo

提案方式(1)事前にID登録と鍵共有を行う。

DRokuboX @drokubo

提案方式(2)逆認証方式。逆とは、クライアントがサーバを認証する。 #3D1 #scis2012

DRokuboX @drokubo

モバイル端末によるサーバの認証は、事前に登録したIDやパスワードを使ってできる。サーバによる端末の認証は、事前に共有した鍵による暗号化通信。 #3D1 #scis2012

DRokuboX @drokubo

リプレイアタックに対しては、シリアル番号や有効期限。第三者による傍受は、暗号化+ハッシュでふせぐ。 #3D1 #scis2012

DRokuboX @drokubo

必要なもの、安全な保存領域や、事前準備における安全な通信など。 #3D1 #scis2012

DRokuboX @drokubo

プッシュ通信は、制御用？のSMS通信でよい？→Yes. #3D1 #scis2012

DRokuboX @drokubo

座長：一度プッシュ、認証した後、プルによる通信を行うことだが、認証はプルになってからでないといけないのか？→リプレイアタックによる電力消費などの攻撃を心配している。 #3D1 #scis2012

DRokuboX @drokubo

3D1-2 暗号化データベースにおける範囲検索 #3D1 #scis2012

DRokuboX @drokubo

データを完璧に暗号化すると、データベースの利便性が失われる。

DRokuboX @drokubo

準同型暗号,順序保存暗号などを使えば、暗号化したままでも検索が可能になり、利便性が回復 #3D1 #scis2012

DRokuboX @drokubo

順序保存暗号を使わないと、データベースを利便的に使えないが、安全性に問題がある

aoki @ringohub

RT @k4403: 忍者きた！ #scis2012 http://t.co/dKa5lm7O

拡大

DRokuboX @drokubo

順序判定可能暗号を使う。と、ソート→暗号化の際、順序判定暗号してから、通常の暗号化する, #3D1 #scis2012

DRokuboX @drokubo

暗号化したままで、順序を維持しつつデータの検索や挿入ができるのか。

DRokuboX @drokubo

最低限の情報開示をするというのが安全性の要件かな

Toshihiro Ohigashi @higa_t

RT @k4403: 忍者きた！ #scis2012 http://t.co/dKa5lm7O

拡大

@expl01t

コスプレだん。通常の委員に戻ってナイトセッションの準備にとりかかる。タイトル頂いてない人は早めにお願いしま～す。 #scis2012

DRokuboX @drokubo

接頭保存暗号は、2つの平文の接頭に同じビットがあると、比較鍵も接頭部分が同じになるもの。 #3D1 #scis2012

DRokuboX @drokubo

三菱電機平野さん：順序保存との違いは、判定鍵を作るというのが違う？→ある値より大きいという最低限のことがわかる、ということの違い。 #3D1 #scis2012

DRokuboX @drokubo

尾形先生：ソートはできないんですか？→既にソートされているものに対して使うのが前提です。 #3D1 #scis2012

DRokuboX @drokubo

3D1-3 失効を考慮した関数型暗号システム #3D1 #scis2012