Secure Scheme Script Suite
Upcoming SlideShare
Loading in...5
×
 

Secure Scheme Script Suite

on

  • 1,287 views

 

Statistics

Views

Total Views
1,287
Views on SlideShare
839
Embed Views
448

Actions

Likes
0
Downloads
0
Comments
0

4 Embeds 448

http://shibuya.lisp-users.org 429
http://localhost 16
http://shibuya-lisp.github.com 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Secure Scheme Script Suite Secure Scheme Script Suite Presentation Transcript

  • Secure Scheme Script Suite (Squad) ~~TOD~~ Shibuya lisp technical talk #7 1
  • 自己紹介• 1974年i4004を使った装置製作でプログラミングを学ぶ• 1981年K&RのC言語を学ぶ• 1982年前後でLisp, Prologに興味を持つが挫折する• :• :• :• 2010年セキュアなプログラム開発環境が欲しくて調査、 Lispに興味を持ちcampuslispにセキュリティを組み込 んでみる• 2011年Rubyにセキュリティを組み込もうとして断念し minischemeにセキュリティを移植する検討を始める• そして今日、まだSchemeの全てを知らない素人! 2
  • Agenda 技術編 SecureなScript言語の必要性 SchemeがSecureであるために ObjectへのSecurity属性とTypeの追加 定義や設定内容を保持するために パスワード認証を安全に行うために 認証後の入出力はSecureに リモート入出力としてのソケット通信 セキュリティ組み込みによる制限 New Syntax & Procedure 既存SyntaxとProcedureの制限 デモ デモの構成 アクセスコントロール機能と権限確認方法の紹介 ビジネス編 Script言語のすむ世界 Script言語を使ったアプリは何故商売に向かない? Script言語だから!!! セキュリティウォーズ S-quad + Backup-base ⇒ DROID 3
  • SecureなScript言語の必要性• コンパイル型言語はセキュリティ機能を持つ • ソース無しでの解析・改ざんは困難 • 脆弱性テストが確立している • セキュリティ機能組み込みは実装者に依存し強度が不定?• Script言語はセキュリティが無い • 起動時に読み込ませるためソースコードが丸見え • ソースコード解析・改ざんは容易 • 使用中、勝手に関数利用や変数内容変更ができる • 利用者に楽しいプログラミングの世界を開放している• 解決策はセキュリティ! • さて… 4
  • SchemeがSecureであるために• 変数の値を勝手に知られたくない • 読み出し時には権限を確認する (Eval)• 変数を勝手に変更されたくない • 書き込み時には権限を確認する (Mod)• 関数コードを不用意に見られたくない • 関数読み出し時には権限を確認する (Eval)• 関数コードを勝手に変更されたくない • 関数変更時には権限を確認する (Mod)• 関数を勝手に実行されたくない • 関数実行時には権限を確認する (eXec)• 権限確認用パスワードを他の人見られたくない • 権限を持つ人が設定できその後は自らも簡単に見れないように• パスワード認証後は通信も秘密にしたい • 暗号化通信を行う(Encrypt) 5
  • ObjectへのSecurity属性と表記Type、表現形式の追加• Object Cell に評価・変更・実行用 ロックフラグを用意 する• Object Cell に権限確認パスワードとのリンクを張る• パスワード用途のObjectとしてBlock Type (128 bit) を追加する• Block Type データを保持するBlock Segment を 追加する• Block Type の表記にはHexa Decimal と Base64を用いる• ファイルバックアップ、相互通信にはBase64エンコード を利用する 6
  • 変数タイプと属性の追加(例) • /* cell structure */ • struct cell { • #define T_STRING 1 /* 0000000000000001 */ • unsigned short _flag; • #define T_NUMBER 2 /* 0000000000000010 */ • struct cell *_osec; • #define T_SYMBOL 4 /* 0000000000000100 */ • union { • #define T_SYNTAX 8 /* 0000000000001000 */権限鍵と• struct { • #define T_PROC 16 /* 0000000000010000 */のリンク • #define T_PAIR 32 /* 0000000000100000 */ • char *_svalue; • #define T_CLOSURE 64 /* 0000000001000000 */ • short _keynum; • #define T_CONTINUATION 128 /* 0000000010000000 */ • } _string; • #ifdef USE_MACRO • struct { • #define T_MACRO 256 /* 0000000100000000 */ • short _nb; • #endif • unsigned short _bver; • #define T_PROMISE 512 /* 0000001000000000 */ 128 • #define F_EVALLOCK 1024 /* 0000010000000000 */ Bit• bpointer _pblock;Block • #define F_MODLOCK 2048 /* 0000100000000000 */ • } _blocks; • #define F_EXECLOCK 4096 /* 0001000000000000 */ • struct { • #define T_BLOCK 8192 /* 0010000000000000 */ • long _ivalue; • #define T_ATOM 16384 /* 0100000000000000 */ • } _number; • #define CLRATOM 49151 /* 1011111111111111 */ • struct { • #define MARK 32768 /* 1000000000000000 */ • #define UNMARK 32767 /* 0111111111111111 */ • struct cell *_car; • struct cell *_cdr; • } _cons; Security Flag • } _object; Block 7 Type • };
  • 定義や設定内容を保持するために• Backup 機能の組み込み • その時点の状態をScheme式に逆変換し特定のパスワードで保護しファ イルに保存する• Resume機能の組み込み • Backup ファイルは起動時に自動読み込みしScheme を初期化する• セキュアな関数定義 • 関数定義では使用する関数・変数が持つセキュリティ属性を確認しそれ らが前もって認証済みであるか確認する• 操作権限委譲 • 定義済みの関数はその関数が利用する関数・変数のセキュリティ属性 かかわらず評価、実行できる• 削除機能の追加 • 定義済み関数・変数を未定義化する構文undef を追加• アクセスコントロール • 評価・実行時はそのSymbolのセキュリティ制限にしたがう• Shutdown時の考慮 8 • 終了時は内部状態を暗号化しBackupする
  • パスワード認証を安全に行うために• 乱数を用いたパスワード交換 • 乱数をパスワードで暗号化し相互に交換するアルゴリズムを用 いて平文のパスワード交換を無くす• モジュール分割した認証 • パスワード保持プログラムを他のモジュールに用意しパスワード チャレンジに対しレスポンスを確認し認証する• 認証リスト • 複数同時認証を可能とし認証済みのObject は認証リストに登 録しObject利用時にスキャンし確認する• 認証切り替え • 認証を切り替えるには今までの認証記録の消去がされ、新たに 認証リストが作成される 9
  • 認証後の入出力はSecureに• ローカル入出力 • キーボードを用いた入力は利用環境をセキュアーにする前提で平 文による入出力• リモート入出力 • リモート入出力のポートの組み込みで外部からの指示を受け付け る • リモートポートからのキーボード入力に対しては通信を暗号化する • パスワード認証時に交換する乱数をセッション鍵として利用する • 通信パケットにカウンターを組み込みリトライ攻撃を防止する • 通信入力データを復号し結果を同じセッション鍵で暗号化し返信 する 10
  • リモート入出力としてのソケット通信機能を組み込む• モジュール間通信 • ローカル入出力からソケットを介し他のモジュールと通信する機 能を持つ• リモート制御 • リモートプログラムはスクリプトをソケットを介して送信し結果を受 信する • 認証パスワードを保持し乱数を用いたチャレンジパケットを生成 送信しレスポンスを解析する(外部認証) • 相手からのチャレンジパケットを受信し乱数を用いたレスポンス パケットを生成し送信する(内部認証) • 相互に認証が成功した以降の全ての通信は暗号化するモードと なる 11
  • セキュリティ組み込みによる制限• 暗号通信機能の追加 • 認証後はデータをセッション鍵で暗号化しその結果を印刷可能な コードBase64に変換し送信する • 受信したコードをBase64で逆変換し、その後セッション鍵で復 号してデータを得る• 組み込み関数動作制限 • セキュリティフラグが設定されているObjectの利用には認証が 必要 • 関数定義で組み込む関数・変数は前もって定義され認証済みで あること • 定義済み関数の利用時はその関数に組み込まれた関数・変数 の認証を再度必要せず、定義関数に設定されたセキュリティ属 性のみに従う 12
  • New Syntax & Procedure 1• backup • define した関数と変数も含めた最新の内部表現を外部表現に 変換してバックアップ• undef • Define した関数・変数を削除する• setsym • Symbol にセキュリティフラグ(EMX)と認証鍵をセットする• reqsym • セットされたObjectのセキュリティフラグ(EMX)確認• auth1 • 相互認証Pass 1• auth2 • 相互認証Pass 2 13
  • New Syntax & Procedure 2• ex-auth1 • 外部モジュールとの相互認証 Pass 1 (auth1の生成送信)• ex-auth2 • 外部モジュールとの相互認証 Pass 2 (auth2の生成送信)• start-minion • モジュールへの外部制御を許可する• conn-minion • 外部モジュールに接続する• req-minion • 外部モジュールとの通信• 状態確認関数 • auth-mode, get-minion 14
  • 既存SyntaxとProcedureへの制限• define • 引数は定義済みであり且つセキュリティフラグを確認し認証済み であることが続行条件• eval • 引数にTLO*が有ればそのセキュリティフラグを確認し認証済み であることが続行条件(Closureは除く)• apply • TLO*のセキュリティフラグを確認し認証済みであることが評価 続行の条件• set!, set-car!, set-cdr!, • TLO*のセキュリティフラグを確認し認証済みであることが変更 実行の条件 *TOL: Top Level Object 15
  • 相互認証方式の例 _ra _rb 0101……….80 0101……….80a ENC ENC a’ ENC ENC M1 M3 ENC b’’b ENC _key DEC DEC _key ENC ENC M4 M2認証アルゴリズム 1 認証アルゴリズム 2 DEC DEC _ra == _ra1 _rb1 _ra1 _rb1 _ra1 16 _rb == _rb1
  • デモの構成 ninja Display xxx2 .escm Ninja2KB ninja ninja ninja xxx1 xxx4 .escm .escm Ninja1 Ninja3 xxx3 .escm 17 Ninja4
  • Demonstration Bug still alive 18
  • Script言語のすむ世界(私見)• Script言語は脇役であり主役になれない • チョイ作りにはとても便利だがしっかり作るときはCompilerで 高速化 • ユーザーに機能の部分開放目的で他のソフトにバインドされる • Scriptその物の販売では商売にならない• 高級言語の上に位置する上級言語 • Compilerで組み込まれた上級言語 • 要求仕様作成言語? • テスト仕様作成言語?• 住んでいる世界は • SIの道具として机の中、思考訓練用途で頭の中、実行アプリの ポケットの中、暗いQAテスト機の中、解説書の本の中• 将来も安泰か? • CompilerがVMと結託して攻めて来る • 自分を守れれば生きながらえると信じよう! 19
  • Script言語を使ったアプリは何故商売に向かない?• ソフトの知的財産権が守れない • 複製検出が出来ない • 勝手に機能追加できてしまう• サポートが出来ない • トレーサビリティ機能を組み込む事が難しい • ソースコードの勝手な変更によるトラブルのサポートが出来ない• 単一個別要求に向くので • 趣味の世界 • プロトタイプモデルの開発 • 検査機のテストスクリプト• ビジネスにするとしたら • やっぱり解説書でアカデミックに! 20
  • Script言語だから!!!• ライブラリー化されやすく教育に便利 • Script言語で作成した実行プログラムは可読性が高く、再利用が容易 で、ライブラリー化され易く、先人の知恵を学べる• 柔軟な機能修正 • REPL構造により、組み込んだ定義を更に評価対象として修正定義出 来る事が大きな特徴• 柔軟性の裏返し • Script言語の実行プログラムが編集可能なため脆弱性が生まれてし まうが、実行プログラムへのアクセスコントロール機能が組み込まれると その弱点は消えていく• 脆弱性対策 • 一度組み込んだScriptが実行モジュールとして一体と成りScriptの再 読み込みを必要としない構成であれば、Compiler言語による実行モ ジュールと秘匿性に対する相違が無くなりScript言語の良さが際立っ てくる• 便利で安心に • アクセスコントロール機能の活性化をフィールドで行うなどの柔軟性が 組み込こめるのはScript言語の特権である 21
  • レイヤー構造とロールの違い Edit CompileApplicationProgrammer Applimenter Test Squad Upload Applet Script Application + Implementer Virtual Machine Squad = Applimenter Operating System Device Driver Hardware 22
  • Squad ApplicationsSq-Scheme Sq-Java/Scheme Sq-Ruby Sq-Python IC Card Sq-Scheme Sq-Scheme Sq-Scheme 23
  • S-quad + Backup-base⇒ DROID• シナリオを分解し、スクリプトとしてアクターに表 現させ、劇を完成させる静的な世界から飛び出し、• アクターはスクリプトを読み込み租借して進化す る知能を持つものとし、• ダイナミックなネットワーク構築と階層化で集団と して進化を可能とさせる• Droid Epic Compile を目指すDynamically React-able Object by the Internet Device 24
  • Droid Scheme Net 25
  • ご清聴有難うございました 門外漢の視点でした 26