第1回セキュアシステムシンポジウム参加メモ

産総研 RISEC: 第1回 セキュアシステムシンポジウム

情報セキュリティ技術開発の現状と産総研への期待（三菱電機株式会社　情報技術総合研究所情報セキュリティ技術部長　松井充氏）

広がる組込暗号

  • 携帯電話、ETC、純正品認証(インクカートリッジとプリンタ)

Lightweight Cryptography（軽量暗号）

  • KASUMI(1999), AES(2000)が契機
  • ISO/IEC 29192で標準化が進行中
    • ブロック暗号ではPRESENT, CLEFIAが選定
  • ハードウェア実装の比較はしばしばtricky
    • プロセス、セルライブラリ、実装者、比較方法、etcに依存
  • 64bitブロック暗号復活
  • 解読の研究も盛んに行われている

組込みシステムにおける暗号実装の実際

  • 暗号の性能用件は与えられるもの
  • 「このサイズでこの速度がでる」との情報とともに「このサイズでこの速度はでない」との情報が重要
  • 属人性が避けられない

Ciphersと(理論的)安全性

  • 暗号の安全性は「棒高跳び」
  • すでに64ビットブロック暗号を許容している
  • 製品寿命を考えると...
  • 安全性の要件を緩和して、さらに軽量化する方向もあり得る

クラウド向け暗号技術の目指すもの

  • ユーザは情報を暗号化してサーバに登録。サーバはそれを復号せずにサービスを提供

関数型暗号

  • 公開鍵と秘密鍵を任意の関係式で対応付けることができる
  • 1つの公開鍵に対し複数の秘密鍵を対応させることが可能

関数型暗号の応用例

  • コンテンツの所有者が、その属性を指定して暗号文の中に埋め込む。コンテンツ利用者はコンテンツ所有者から利用したいコンテンツの種類に応じた復号鍵を購入する。
  • 同報通信でありながら受信者を指定したり排除したりすることができる

関数型暗号のインパクトと今後

  • 新しい公開鍵暗号の「統一理論」
  • 関数型暗号でなければならない応用があるか？
  • 関数型暗号のキラーアプリ(＝ビジネスモデル)は何か？


スマホアプリのプライバシー問題の解決に向けて（セキュアサービス研究グループ　高木浩光氏）

ウェブからスマホアプリへ

  • ウェブ
    • セキュリティ制約による厳しい機能制限
      • 収集できるのは利用者が自発的に入力した情報に限られる(同意確認不要)
  • スマホアプリ
    • 中間的な緩さの機能制限
    • 個々のアプリ提供者の裁量 → 新しい問題が発生

Permission確認方式の限界

  • 使用と送信の許可が独立
    • 「送信しない使用」と「送信する使用」を区別できない
      • 使うが送信しない例：広告表示(完全なインターネットアクセス)

基本的な考え方

  • 利用者の意図に反した動作にならないようにする
  • 歴史的経緯（国際的な）を踏まえる
  • サービス実現のための技術的必然性があるか

総務省提言の内容

  • オプトイン方式を基本に
  • 端末IDは「個人情報に準じた形で取り扱う」
  • アプリ単位でのプライバシーポリシーの策定


The Future of Web Security (Ian Fette)

Securing the Access Point

  • Sandboxing
    • Run code in restricted envirnment with highly limited privileges
    • Sandboxing everything
      • Sandbox the browser
      • Sandbox the renderer
      • Sandbox the plugins
    • Isolate content from different sites
  • Native Client
    • Run arbitrary native (C++) code in a sandboxed environment
    • Validate that only allowed code is run
    • Mediate all access to outside system
  • ChromeOS
    • Verified boot
    • Automatic updates
    • Encrypted local data storage
    • Fast user switching with "guest" mode
    • No native apps - everything runs within the Chrome security model

Securing the Platform

  • Same origin policy
    • Goal: prevent one website(origin) from accessing content on functionality of another website
  • Cross Site Scripting (XSS)
    • Can be used to infect users with malware, or perform operations on that website while logged in as that user
    • Reflexive XSS filter can help prevent many XSS attacks
  • Clickjacking
    • User thinks they are clicking one thing, actually clicking another
    • X-Frame-Options provides a website anti-clickjacking protection
  • origin:header
    • Same Origin Policy forms the core security policy on client
    • Server should be able to enforce SOP in server logic
  • Certificate Pinning
    • SSL certificates provide protection for an origin
  • Scan Downloads
    • We prevent malware rom being installed automatically by sandboxing, but users can still download and install malware!
    • Protect against "social engineering"
  • Detect Phishing Faster
    • Detect visual similarity of pages instead of relying on blacklist
    • Compare logos on page to set of known phishing targets
  • Don't ask the users
    • Users aren't always better decision makers than programmers