1はじめに
昨今，研究成果の捏造が社会問題となったことは記憶に新しい.技術的にこれらの問題の発生を食い止める事は困難であるが,改竄が困難な手法によって研究記録が保存されているならば、少なくとも研究記録の検証に関しては大いに助けになるであろう.この際、研究記録の真正性と非改竄性の保証をいかに行うかが課題となる.このような課題に対して,原田らは電子カルテを念頭に,モデルの提案を行っている[1].また,陳らはXML文書の時刻認証を伴った管理を試みている[2].同様なサービスとして, SNS/blog機能に電子文書へのタイムスタンプ付加機能を加えた, SNS/blogサービスも存在する*'.しかし、これは日本電子公証機構のサービスを利用しているため、比較的高額なサービスとなっている.このような,タイムスタンプを活用したサービスはDVCS (Data Validation & Certification Server Protocol)やTAP (Trusted Archival Protocol)などに分類される. DVCSは,電子文書のアーカイプは行わないことを原則としており,対してTAPはアーカイプも行うことを原則としている.また宇根らはDBCSやTAPで用いられる各種タイムスタンプによる可用性・安全性に関して報告している. [3]また,今日，e-mailやWorld Wide Webに代表されるインターネット環境は,多くの人にとって重要なコミュニケーション・メディア/コミュニケーション・ツールとなっている.そのようなネットワーク環境を利用し,関連した研究を行う者同士が,論文の公刊前に,研究の進め方や研究・実験の成果について互いに意見交換が可能な環境が提供されれば、研究を進める上で大きな利点があると考えられる.そして記録,コミュニケーションと並んで,コンピュータが果たすことができる重要な役割として,ストレージ機能がある.研究資料や実験試料,あるいはプログラムなどを手軽に公開・参照できる機能が実現できれば，研究者間での研究資料や実験試料などの流通も盛んになり,研究自体が活性化するであろう.ただし,記録機能においても,ストレージ機能においても,研究の遂行途中においては一般には秘匿したい,あるいは秘匿する必要のある情報も存在する.そのため,情報を公開する範囲を柔軟に制御できなければならない.現在, World Wide Webを用いたSNSなどのサービスにおいて,記事の公開範囲はある程度の制御が可能ではあるが，概ねその設定の自由度は低い。 Masuiらや江渡らは, QuickML[4]やqwikWeb[5]により,情報にアクセスできる者を柔軟に変更可能とするシステムの構築と運用を試みた.また, SNSを基盤としたシステムとして,永田らはEnzinを[7],高井らはACSを開発し[6],運用実験を行った.高田らは,公開Web- DBとWeb-DB管理システムを分離可能であり,かつきめ細かなアクセス制御が可能なWeb-DB管理システムを構築している[8].また、一般のSNS/blogにも、記事ごとに公開範囲の設定を可能とするサービスが登場しており*,公開範囲の柔軟な制御の需要が伺える.本研究では上述のような研究記録などの管理を主目的として,公開範囲を柔軟に変更可能かつ,記録の真正性および非改竄性を可能な限り保証する,研究記録の管理・公開・検1証を行うシステム, arχves 5の構築を試みた.特に,安価かつ, DVCSでもなく,またTAPでもない，第三のあり方を模索した.
2システムの特徴
2.1概要
本システムは、研究記録などの管理を主目的とし、公開範囲を柔軟に変更可能かつ、記録の真正性および非改竄性を可能な限り保証するシステムの構築を目的としている.そこで,データの記事の真正性と非改竄性の保証をある程度可能とするために,記事データの投稿時に,記事データに対して二重署名の処理を行う実装を行い,また平易な操作で検証を行えるようにした.また,電子情報の簡便な記録•保存と扱いやすさのために,基本的な操作は近年広く普及しているSNS/Blogをベースとした実装とした[17].そして柔軟な公開範囲の実装のため,一般のSNS/BlogのようにBlogコンテンツ全体の公開範囲を指定するではなく,投稿される記事ごとに公開範囲を指定し,公開範囲の設定段階も自由度の高い指定を可能とした.特徴を要約すると,以下の３点となる. ●　真正性と非改竄性の一定の保証を可能とする,電子データに対する署名および検証機能●  SNS/Blogをベースとした実装●　記事ごとに公開範囲の指定を可能以降の各節で機能の詳細について説明していく.
2.2 利用ツール
本システムで使用したツール等を表-1に示す. Ruby on Railsは本システムの基幹となるSNS/Blog機能の構築を中心に活用し,データベースにはMySQLを利用した.電子署名の付与および検証については,全てGnuPGを活用している.

2.3.1 検印モデル
企業における,記録の真正性および非改竄性を保証する方法として,部下が書いた記録(日報など)に,上司が検印を捺すことが広く行われている.このような,記述者とは異なる者が検印あるいはそれに類する行為/操作を行うモデルを,本論文では「検印モデル」と呼ぶ.検印モデルの例としては,原田らは,公開鍵暗号を用い,記述者が自分自身の秘密鍵で電子署名をすると共に,文書管理システムに持たせた秘密鍵を使った電子署名により検印をするモデルを提案している[1].本論文においても,この検印モデルを採用した.ただし,原田らの提案においては,文書管理システムが検印を行うが,本論文で述べるシステムにおいては,記事やデータに検印を行うサーバ(以下「検印サーバ」)と,文書を保管するサーバ(以下「文書サーバ」)」は異なることを想定している.文書サーバは,ユーザが通常,記事を記述する際に用いるサーバとした.これはタイムスタンプ技術[9]と類似しているが,文書作成者の真正性を,ユーザ自身の電子署名という形で明示的に示している点が異なる.検印については,大学規模の組織を越えて,相互に検印を行うモデルを想定している.このようにシステムを分散することで，導入および管理コストの低減を期待している.このようなシステムの利用サイトが相互に検印を行う手法により,真正性や非改竄性の保証の強度は,企業が提供するサービスに比べて幾分低くなると思われる.しかし,企業が提供するタイムスタンプ・サービスは高価であったり、利便性に欠ける部分がある.そこで，本論文で示すシステムと,企業が提供するサービスとは使い分け/棲み分けができると考えられる.また,ラボノートの運用および証拠能力から,本システムも十分な能力を持っていると考える.
2.3.2 検印モデルによる実装
記事を記入後，投稿ボタンをクリックすることで以下のような手順で二重署名が行われる. ①投稿された記事に対して,文書サーバがユーザの秘密鍵で署名を行う. ② ①で作成されたデータを検印サーバへ転送③文書サーバから送られたデータに対し,検印サーバがタイムスタンプを記録し更にデータ全体に対し署名を行う.そして,署名部(図1, 2参照)のみを検印サーバは保存するる. ④検印サーバは文書サーバに２重に署名済みのデータを送り返す⑤）文書サーバにデータを保存以上の一連の流れをを図式化したものが図1である.図2は,実際に二重署名が行われた文書の構成を示している.文書サーバと検印サーバ間のデータの通信には,データ保護のためSSLを用いている.また文書サーバと検印サーバのそれぞれで行われる署名の直前に,データに対して時刻情報を書き込み,タイムスタンプのシンプル･プロトコルと同様な作業を行っている.一般的に普及しているタイムスタンプではデータ漏洩への対策も考慮し,ハッシュ値を用いてデータの非改竄性の保証を行っているが，本研究では閲覧者がスクリプトによらない検証を行えるようにする為, Clear署名*4で2重署名作業を行っている(参照: [2.3記事の真正性と非改竄性の保証」). -----BEGIN PGP SIGNED MESSAGE-----S Hash: SHA1↓ →サーバ署名( Sign2 )時のヘッダ- ------BEGIN PGP SIGNED MESSAGE----- Hash: SHA1↓↓ ーザ署名( Sign1 )時のヘッダlogeとなったは記憶に新しい。昨今，研究成果や論文の捏造の問題が社事
れらの問題の発生を食い止める事は困課改竄が困難な手法によって研てある方か,も研究記録の検証に関しては大いに助究記録が保存されているならば，少なく
Iけになるであろう。↓投稿された本文部分ClientTimeStamp: 2008-08-06 13:48:10+
- -----BEGIN PGP SIGNATURE-----↓ Version: GnuPG v1.4.9 (MingW32)+ i EYEARECAAYFAk i ZLQoACgkQF uywYqu77 i AEgCgoydo8cs8dh2HHbf2Pq15/ThQ4 w2kAoMPvYX1VvotE6Hq1hEzoA05+WqTU+ =YT/d ↓ ---END PGP SIGNATURE-----↓ L Server TimeStamp. 2008-08-06 13:48:12↓ -----BEGIN PGP SIGNATURE-- Version: GnuPG v1.4.9 (MingW32)+ iEYEARECAAYFAkiZLQwACgkQNkcjG4aWrL1LIQCfbe1jcjy3ypHIHm4RCSigU9/B4 dVgAnjiya7G9hrjNowSbI5nrAEi25sZq↓ =5xCX+ -----END PGP SIGNATURE-----u
図2   2重署名された記事データの構成
2.4 記事および添付ファイルに対する検証機能
前節で二重のデジタル署名によって,投稿されたデータの真正性および非改竄性の保証が行われているが,それが確かであるかどうかは署名の検証作業によってのみ確認が可能である.また,電子商取引推進協議会,認証・公証WG [15]のガイドラインでは,デジタル署名の有効性を長期的に維持する為の用件として,次の４つを挙げている. 1. 署名検証時に,署名再検証に必要な情報を明確にしておくこと2.署名検証時の時刻を明確にしておくこと3.署名再検証時に必要な情報を改竄検出可能な状態にすること. 4.署名再検証時に必要な情報を保存すること(1)は、検証を行う際に確かにその署名が有効であることを示す情報(あるいは失効情報)を明示しておくこと.そして,署名の検証が確かに保証されていることを確認した日時を明確にし，(2)その時点まで確かにデータの保証されていることを記録し，(3)再検証を正しく行えるように改竄をの検出を可能にして, (4)署名の再検証に必要な情報を保存して,第三者でも再検証を行えるようにしておくということである.これらの用件を満たすことがデジタル署名の有効性の長期的な維持には必要であるとされている.このように,本当にその署名が確かであることを確認したり,あるいは長期的な有効性の維持には「署名の検証」が必要となってくる.本システムでは,その検証を簡単に行える機能を実装している.各記事およびデータには,「簡易検証」機能および「通常検証」機能が用意され,閲覧者はそれらのリンクをクリックすることで簡便な検証を行なえる.なお,「簡易検証」は文書サーバのみで,ユーザの公開鍵と検印サーバの公開鍵を用いて行う検証である.通常検証は,検印サーバに記録されている署名データとの照合も含めて検証を行う.検証を行なった画面例を図3に示す.また,改竄が行われた場面の画面例を図4に示す.しかし,本システムはコンピュータ•プログラムとして実現されている以上,スクリプトを書き換えることにより,あたかも検証を行なったように見せかけることも可能である.そのため,関覧者が独自でも検証を行なえるよう,ユーザおよび検印サーバの公開鍵は画面上から取得可能としている(図5) .検証手順については,プログリストのサイドバーから,手引きを参照できるようにしている.検証結果投稿者:管理者検証記事タイトル:公開鍵暗号を用いた研究記録管理投稿日時: 2008-08-27 13:54:37ユーザ主鍵フィンガープリント: F4BB BDCE 667 7ACB 60AE AC0B 15FB B2C1 8AAE EFB8検証結果:サーバー署名gpg: 08/27/08 13:54:39にこDSA銀ID 8696ACBDで施された署名gpg: " server (sarver's key) "からの正しい著名検証結果:ユーザ署名gpg: 08/27/08 13:54:37にDSA額ID 8AAEEFB8で施された署名gpg: “MikuKatou ”わらの正しい署名gpgこの署名が所有者のものかどうかの検証手段がありません。主鍵の指紋: F4BB BDCE 667 7ACB 60AE AC0B 15FB B2C1 8AAE EFB8検印サーバ側の署名部との照合結果検断回サーバ側の署名部と一致しています。ユーザ署名とサーバ署名が共に一致しています。図３検証結果(成功時)検証結果投稿者:管理者検証記事タイトル:公開鍵暗号を用いた研究記録管理投稿日時: 2008-08-29 14:56:22ユーザ主鍵フィンガープリント: F4BB BDCE 667 7ACB 60AE AC0B 15FB B2C1 8AAE EFB8検証結果:サーバー署名gpg: 08/29/08 14:56:23にDSA解説ID 8696ACBDで施された署名gpg: “ server (sarver's key) "からの不正な署名検証結果:ユーザ署名gpg; 08/29/08 14:56:22にDSAfiEID 8AAEEFB8で施された署名gpg: “MikuKatou ”からの不正な著名検印サーバ側の署名部との照合結果検EDサーバ側の署名部と一致していますユーザ署名とサーバ署名が共に一致しています。図４検証結果(失敗例*5)
図5 公開鍵のダウンロード画面
2.5   SNS/Blogベース
2.5.1概要
本システムは,研究室〜学科程度の規模を単位としての記録の保存を想定しており,過度に分散せず,過度に集約せず,適度に分散しつつネットワークを構成するシステムを想定している. それに加えて電子情報の簡便な記録・保存と扱いやすさのために,基本的な操作は近年広く普及しているSNS/Blogをベースに実装している.本システムにアクセスすると図6のようなトップページコンテンツが表示される.ここでユーザとして認証を受け，ログインすると，図７のような画面になる.
アカウントを持っている方はサイドバーにあるフォームからログインしてください。自分のアカウント体報や投稿した記事やグループの修正は、ログイン後画面右上の「○○さんの」
アカウント」という文字に頼られたリンクから行えます。いをしなくても、ブログリストから全体公開されている記事の閲覧は可能です。記事殺稿者及び署名サーバの公開鍵及びフィンガープリントは二ちらから。図6  TOPページ(初期表示)ジ(ゲスト・ユーザ認証後)ページは大きく上からメニューバー,メインページ(左) ,サイドバー (右)で構成されている(図8).メニューバーには各コンテンツへのリンクが張られており、メインページには各コンテンツの内容が,サイドバーにはコンテンツ内のサプコンテンツ•関連ページへのリンクやコンテンツ内の検索機能が表示される.またログインすることでメニューバーの右上部にアカウント名が表示され,アカウントメニューへのリンクとログアウト用のリンク*6が表示される(図右上部丸).メニューバーおよびサイドバーは,ログインした利用者の権限ごとに表示されるコンテンツが異なる(詳細は「2.5.2利用者の分類」).以下でコミュニティを形成する利用者およびグループや,利用者による記事の投稿をメインとした交流とその管理を行う為のコンテンツ毎の機能について示す. *6各図とも分かりやすさのために「管理者」｢ユーザ｣などと表示されているが,実際はハンドル名が表示される.
2.5.2　利用者の分類
本システムの利用者は、本システム上に何らかのアカウントを持っている.このシステムの利用者は、システムを利用できる権限によって「ゲスト」,「ユーザ」,「管理者」に分類される.利用者ごとの大まかなアクセス権限を示したものが表2である. 「ゲスト」は,システム内のblog記事の投稿やグループの作成は行えないが,グループに所属し、記事の閲覧は可能な利用者である. [ユーザ」は,システム内に自身のblogを作成し,記事を投稿することができる利用者で,グループの新規作成や，自身のアカウント情報を修正することができる.また，自身が投稿した記事の各々について公開範囲の変更や,カテゴリの変更が行える. 「管理者」は,システムの管理者であり,管理者メニューにアクセスできる唯一の利用者である.本システムはTOPページからIDとパスワードを利用したユーザ認証を受けてログインすることで,利用者の権限に応じてコンテンツが表示される.また,システムにログインしていなくても,公開範囲に制限を加えられていない記事に関しては閲覧が可能である.表中にある「アカウントメニュー」はログインした利用者自身の情報の編集，削除が行えるコンテンツであり,また「管理者メニュー」はシステム全体の各データの編集,削除が行えるコンテンツである.このアカウントメニューと管理者メニューの項目については表３に示す.

2.5.3グループについて
グループは,一人以上の利用者からなる利用者の集合である.その種類は,階層別に「ル一トグループ」,「トップレベルグループ」,「子グループ」に分けられる(図9).ルートグループは,アカウントを持つ利用者全てが所属するグループである.そのため,利用者は必ず一つ以上のグループに所属していることになる.トップレベルグループは,ルートグループの直下に作られるグループであり,利用者が自分で作成できる一番上位のグループである.子グループは,トップレベルグループよりも下層に作られるグループを指す.必ず親としてトップレベルグループか,子グループが一つ必要となる.以上より,一つでもトップレベルグループが存在する時,子グループの作成,つまり階層を持たせる事が可能となっている(図9).グループの種類と命名規則についての詳細は表４に示す.

2.5.4　利用者の管理(ユーザリスト)
システム利用者の情報の閲覧は、ログインしている利用者であれば、コンテンツの「ユーザリスト」から誰でも見ることができる(図10). TOPページの名前に張られたリンクから,図11のような画面によって各自の詳細な情報を閲覧できる.ユーザの新規登録および修正や削除は管理者メニューの「ユーザ管理」から管理者のみが行えるようになっている.利用者の, ｢管理者｣, ｢ユーザ｣, ｢ゲスト｣という権限の指定は,管理者のみが設定できる(図12).ただし,利用者自身の情報(アカウント情報)は,ユーザであれば一部の情報(ハンドル名,パスワード,鍵情報,所属グループ,備考)の変更が可能となっている.アカウントメニューの「ユーザー情報の変更」から行える.各表示画面で太枠で囲まれている箇所は，管理者*7のみ表示される.
図10 ユーザリスト(TOPページ)
図11 ユーザリスト(詳細ページ) *7ここでの「管理者」は「グループ管理者」ではなく,利用者の分類(2.4.1)での「管理者」
2.5.5グループの管理(グループリスト)
グループの閲覧はログインしている利用者であれば,コンテンツの「ログインリスト」から誰でも閲覧できる(図13).グループの新規作成は,ユーザと管理者であれば誰でも作成可能となっている.新規作成できるグループは、トップレベルグループと子グループの二つがあり、どちらを作成するか選択できる.子グループは直近の親を指定することで作成することができる.また,子グループを親とするグループの作成をすることも可能である(図15).また、グループの管理は作成したユーザと管理者が行うことができる.この二者を「グループ管理者」と呼ぶ.グループ管理者は,グループの編集,削除,参加者の変更(図17)を行える(図14).そして管理者は,上記に加えてグループ作成者の変更項目が存在する(図16).各グループの詳細な情報は，TOPページのグループ名のリンクから閲覧できる(図18).各表示画面で点線の太枠で囲まれた部分はユーザと管理者,太枠で囲まれている箇所は、管理者*のみ表示される.
図13 グループリスト(TOPページ) ID順| 名前順| 階層順
図14 グループリスト(グループ管理者ページ**)
グループの新規追加
追加図15グループリスト(作成フォーム)グループ情報の編集更新図16グループリスト(編集フォーム) *9グループ管理者ページ:アカウントメニューの「管理グループの変更」と管理者メニューの「グループ管理」詳細表示に戻る|一覧表示に戻る国管理者□ ユーザ□ゲスト□佐藤□鈴木□高橋□田中□ 渡辺□伊藤□山本決定して終了(1/1ページ)図17 グループリスト(グループユーザの変更)
図18グループリスト(詳細ページ)
2.5.6記事の投稿・管理（ブログリスト）
記事の閲覧は,コンテンツの「ブログリスト」からできる.コンテンツへのアクセスは誰でも出来るが，実際の閲覧については記事ごとに指定された閲覧範囲によって制限されている.つまり，公開範囲によってはシステムへのログインをしていなくても記事を閲覧することが可能となっている(公開範囲の詳細は次節「2.6記事毎の公開範囲の指定」).閲覧者が公開範囲に含まれていない記事は, TOPページでは記事内容の代わりに「閲覧権限がありません」と表示されるが，タイトルや投稿日時や記事の検証は行うことができる(図19) .記事の新規作成は，ログインしているユーザと管理者であれば「プログリスト」コンテンツのサイドバーより行える.投稿画面は図20のようなものとなる.タイトル,本文,カテゴリ,公開範囲の指定を行い,記事を記入した後,「プレビュー」ボタンを押すと,投稿はされず,図21のような署名前のテキストのチェックおよび公開範囲の確認ができる.なお,カテゴリと公開範囲は,記事の投稿後にも修正可能である(図22).最後に投稿ボタンをクリックすることで，自動的にシステムにより二重署名が行われ文書サーバに保管される.この二重署名の処理についての詳細は「2.3.2検印モデルによる実装」で述べた通りである.その二重署名も含めた全文を表示したページが図23である.また,各記事にはファイルを添付することができる.このファイルについても記事と同様に二重署名が行われる.添付ファイルのダウンロードは、二重に署名されたままのファイルと、システムが自動的に復号処理を行ったファイルの両方を,記事の詳細ページよりダウンロードが可能となっている（図24）.なお、現在、投稿後の記事の修正・再編集は認めていない．記事の削除については，管理者のみが行える.また,添付データの削除は投稿者も自身の記事のアカウントメニューの「ブログ記事の閲覧範囲の変更／添付ファイルの削除」から行えるが、削除理由を明記した上で削除可能としている(図25).また添付データが存在していた記録が残るようにしている(図26).これは，研究記録の非改竄性を考慮してのことである.このように編集や削除に制限をかけているが，記事などの管理にはDBMSを利用しているので，DBMSを直接操作することにより，記事の修正や削除は可能である．各表示画面で点線の太枠で囲まれた部分はユーザと管理者にのみ表示される.
TOPページ|ブログリスト|グループリスト|ユーザリスト
ブログ公開鍵暗号を用いた研究記録管理■公開鍵のバスClientTimeStamp: 2008-09-10 13:28:41 Server TimeStamp. 2003-09-10 13:28:41公開鍵暗号を用いた研究記録管理 ©95脱覧種限がありません。 2008-03-29 15:41:00|管理者|聞易銭訂|通常銭訂|コメント(0) | category9公開鍵暗号を用いた研究記録管理 ©©図19  プログリスト(TOPページ)

カテゴリ: category3
≪本文≫昨今，研究成果や論文の捏造の問題が社会問題となったことは記憶に新しい。これらの問題の
発生を食い止める事は困難であるが，改竄が困難な手法によって研究記録が保存されているな
らば，少なくとも研究記録の検証に関しては大いに助力になるであろう。
この際，研究記録の真正性と非改竄性の保証をいかに行なうかが課題となる。
≪公開範囲≫
::GROUP2:GROUP11 ::GROUP2:GROUP11:GROUP15 :GROUP2 : GROUP4:GROUP13:GROUP17 : GROUP4:GROUP13
記事公開事務図21  プログリスト(プレビュー表示)
≪本文≫ ■公開鍵のバスClientTimeStamp: 2008-08-29 15:40:59 Server TimeStamp. 2008-08-29 15:41:00 ≪現在の公開範囲≫グループを指定して公開::GROUP10ブレビュー投稿図22 プログリスト(公開範囲とカテゴリの修正)
20

-----BEGIN PGP SIGNED MESSAGE---- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ฿今，研究成果や論文の捏造の問題が社会問題となったことは記憶に新しいこれらの問題の発生を食い止める事は困難であるが，改竄が困難な手法によって研究記録が保存されているならば，少なくとも研究記録の検証に関しては大いに助けになるであろう。この際,研究記録の真正性と非文釈性の保証をいかに行なうかが課題となる。 ClientTimeStamp: 2008-07-16 15:02:05 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkh9jt0ACgkQFfuywYqu77h vwCg4TbT0j6VmA81itgNc918BVcj 57wAoNdd4g3dX7Wi/pKZpEcFoiZdGI/P =m2iZ - -----END PGP SIGNATURE---- Server TimeStamp. 2008-07-16 15:02:05 -----BEGIN PGP SIGNATURE---- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkh9jt0ACgkQNkcjG4aWrL3U1ACeITAQY/cmvgo1/oVYuhRN7h9 4moAoIErpmkVJm9DRuTybs9EbndH217D =oqwK -----END PGP SIGNATURE---- . . .公開範囲::GROUP2 ::GROUP2:GROUP11 ::GROUP4:GROUP13 ::GROUP2:GROUP11:GROUP15 ::GROUP4:GROUP13:GROUP17 --- 2008-07-16 15:02:05 |管理者|簡易検証|通常検証|コメント(0) | category3コメントを書く図23  プログリスト(詳細ページ) |添付ファイル： DB.txt [ダウンロード] 2重署名付きファイル("DB.txt.gpg") [ダウンロード]備考:テキスト資料[聞易検証] [通常検証]図24 プログリスト(添付ファイルのダウンロード)以下のファイルを削除します。ファイル名: DB.txtデータ内容:備考:テキスト資料間違いがなければ、以下に削除理由を書いて削除ボタンを押してください。 ※理由が記入されなければ、削除できません。図25  プログリスト(添付ファイルの削除フォーム) [添付ファイル・ DB.txt [削除されました:2008-08-29 14:57:06]備考:テキスト資料。 ≪削除理由≫削除テスト図26 プログリスト(添付ファイルの削除後の表示)
2.5.7アカウントメニュー
「アカウントメニュー」は「ユーザ」および「ゲスト」がアクセスできるコンテンツで，ログインしている利用者自身の情報や投稿データの編集,削除が行えるコンテンツである(図27).ただし,「ゲスト」は自身のアカウントデータが閲覧できるだけで,編集や削除作業は一切出来ない.メニュー項目については表３を参照.
2.5.8管理者メニュー
「管理者メニュー」は「管理者」のみがアクセスできるコンテンツで，システム全体の各データの編集,削除が行えるコンテンツである(図28).ただし,ブログ記事の本文データの編集は,管理者であっても出来ない.メニュー項目については「2.5.2利用者の分類」の表3に示す.
図27 アカウントメニュー (TOPページ)
ブログ記事管理ブログ記事のカテゴリ及び公開範囲の変更／削除が行えます。コメント管理投稿されたコメントの修正／削除が行えます。図28  管理者メニュー (TOPページ)
2.6記事毎の公開範囲の指定
前述したように本システムでは記事単位で公開範囲を指定することが出来る.公開範囲は大きく「全体公開」,「指定グループ」,「自身のみ」の3種類に分けて指定することができる. 「全体公開」は,システムの認証(ログイン)を受けなくても閲覧可能な公開範囲である. 「自身のみ」は，記事を書いたユーザ自身のみが閲覧可能な公開範囲である． 「指定グループ」による公開範囲は,グループを単位として公開範囲を指定する.この時複数のグループを指定することができる.記述例として「2.5.6記事の投稿・管理(プログリスト)」図21が挙げられる.図21のように,改行を区切りとしてテキストエリアにグループ名を入力することで,公開範囲に含めるグループを指定していく.この時,指定されたグループを上位に持つ子グループも自動的にその公開範囲に含められる(図29).なお,記事の投稿後にも公開範囲の変更は可能としている.閲覧範囲は,記事を書いたユーザ,あるいは管理者のみが変更可能である。 ｢2.5.6記事の投稿・管理(プログリスト)｣の図22に示す.
3類似システムとの比較検証
3.1記事毎の公開範囲の指定
・公開範囲指定のインタフェース
公開範囲を指定する際のインタフェースをEnzin[6], ACS[7],本システムで比較すると表5のようになる. Enzinは直感的に操作できるインターフェースであり、ACSもクリック操作のみでグループなどの指定が可能であることに対し，本稿のシステムは若干分かりにくく手間がかかる.これは本稿ではグループがユーザ全体で共通であるため、グループ数が多くなることが予想されるためである.そのため,グループの一覧を表示させるのではなく,テキストエリアで必要最小限の数を文字で入力することで指定するようにした(詳細は｢2.5記事毎の公開範囲の

・公開範囲の設定段階
同様に, Enzin, ACS,本システムにおける公開範囲の設定の柔軟性を比較すると,表6のようになる.表6に示されるとおり、投稿後の公開範囲の設定の変更の可否はあるが、いずれもその公開段階での自由度はほぼ同じといえる. EnzinおよびACSは,一般的なコミュニケーションツールであるSNSを基盤とし,一般のコミュニケーションの支援を目的として作られている.対して,本システムではシステムそのものは同種であるBlogを基本としたシステムであるが，研究支援として利用することを前提としている.そのため,ある程度記事を公開する対象や内容・目的が限定され,グループの数は多くなったとしても,グループ間になんらかの関係が存在することが予想される.そこで,特に実在する組織の階層構造を反映することを想定し、グループを階層的に定義可能とし、グループ間の関連が分かりやすいグループ設定と公開範囲の指定を可能とした.

3.2   比較:真正性と非改さん性の保持
現在,真正性と非改竄性を保障する既存の技術として,電子文書署名サービス(タイムスタンプサービス)がある.電子文書署名サービスは,一般的に作成した電子データのハッシュ値をサービスを提供するサーバに送り、受信したサーバがその受信日時を記録して署名を行うものである.本項では本人が書いたという真正性の確保も含めた比較のため,サーバには電子文書などと共に，作成者本人の署名も含めて送ったと想定し，比較検証を行う.
・非改算性の保証の強度と検証効率
電子文書署名サービスは，文書作成者とは関連のない第三者である企業が，作成された文書から得られるハッシュ値に基づいて非改竄性の保証を行っており,サービスによっては新聞でスーパーハッシュ値を公開しているものもある.認証を受けた企業がサービスを提供するため,サーバへの進入や,文書作成者と企業の秘密鍵を入手することは非常に困難であり、強度は非常に高いと予想される.また検証は、必要とされた時にサービス提供者に依頼することでその回答を得られる.一方本システムも,作成者と,作成者とは別の第三者に対して署名によってその非改竄性の保証を行っているが，現段階では現実的に完全な第三者による検印サーバの管理の依頼は難しいと考えられるため,電子文書署名サービスに対して強度は劣る.ただし,ラボノートの運用、証拠能力から、十分実用に足る能力を持っていると考える.強度を上げるためには,ユーザおよびシステムの秘密鍵の管理法の改善が課題となる.検証は，基本的に記事の閲覧ページから1クリックで行うことが可能となっている.
・導入・利用のコスト
電子文書署名サービスは, e-文書法(2005)制定以需要が高まり各社で手軽なサービスが提供されるようになっている.なかには,契約会社がデータの受け取りからタイムスタンプまでの作業をシステム化して月額で契約するといったサービスもあるが大掛かりである.また基本的に一文書あたり,あるいは一回当たり10～300円程度の課金であることが多く手軽に利用できるとは言い難い.本システムも導入までに技術的・金銭的なコストを必要とするが，全て企業に一任するよりは金銭的なコストは低く、また一度設置した後は、署名から検証までの煩雑な作業は全てシステム側がバックグラウンドで行える.また現在広く利用されているプログのシステムを基本としているため,操作方法は通常のプログの記事投稿の作業と同様で済み,利用者は署名のための知識を意識せず一定の真正性が保障された電子記録の保存作業が行える.
4今後の課題
4.1セキュリティに関して
本システムの大きな課題として，まずセキュリティの問題がある.真正性の保証については,ユーザの秘密鍵をICカードやUSBメモリなどの外部記憶メディアに保管し、記事を投稿するときにのみにそれを参照することで解決できよう.また、本システムにおいて、成りすましが行われる可能性もある。しかし、ユーザの秘密鍵をICカードやUSBメモリなどの外部記憶メディアに保管することにより,成りすまして記事を投稿することはできなくなる.非改竄性の証明の強度を高めるためには、リンキングやヒステリシス署名、履歴交差などの技術の導入の検討も必要であろう[3, 10].関連して,現在GnuPGに依存したシステムである為、多様な署名方式に対応可能とすることによっても利便性と共に非改竄性の向上が期待できる[11].また電子署名の長期利用に関しては、秘密鍵の危殆化などの問題もあり、評価・検討が必要である[12, 13].同様に一定期間ごとの検証記録を保存することによって,どの時点まで真正性が保持されていたかを証拠として残していくことも今後必要となってくるだろう[14].現状では,検印サーバでの署名のために,記事やデータそのものを通信している.そのため情報漏えいの危険性がある.現在は, SSLでの通信を行うことで対処しているが,情報漏えいの対策として十分とは言いがたい．記事やデータのハッシュ値のみの通信に限ることも含めて今後検討を要する.また,公開鍵の正当性の確保のため,信用の輪(Web of Trust)も含めたPKIの利用の検討も必要であろう.
4.2ユーザインタフェースに関して
柔軟な公開範囲の設定については, 3.1節でも取り上げたとおり概ね既存のものに近い自由度となっている.しかし,ログインしている利用者に対しての公開範囲の指定は現状十分に出来るが，ログインしていない一般に対しての公開範囲は全体公開しか存在しない．今後システム利用者と一般を区別せず、任意の記事に対して特定のパスワードを入力することで閲覧を可能とする公開範囲というものも考えられる.また本システムではグループの階層化を取り入れたが，既存のグループの上位に新たに階層を作成することはできない.木構造の表現を可能とするacts as treeという特殊なカラムの命名規約(MagicFieldNames)かRuby on Railsに存在するので,それを利用したグループの作成も考えられる.また、異なる上位グループを持つグループ同士であっても、そのグループの構成員の間には何らかの関連がある場合も現実にはある.そのような縦方向以外での関連を持たせる実装も含め、今後さらに自由度の高いグループ管理を可能としていくことも課題となる．交流の支援という観点からは,本システム,または本システムと同種のシステムが複数稼動した場合,ゲストが各ユーザのBlogを閲覧するたびに,個々にログインを要求されるのは煩雑である.そこで,本システムあるいは同種のシステム間において,認証のDelegate機能も必要であろう.またRSSの配信やトラックバックなど一般のBlogに存在する機能についても,閲覧範囲が記事単位で可変であるため難しいが、今後必要に応じて検討を要する.同じく一般のBlogシステム・サービスによくある,他システムからのデータのインポート,また逆に他システムへのエクスポート機能の実装も考えられる.研究支援という観点からは,記事中での画像や教式や表・グラフ,化学式への対応も不可欠である.このような問題については,後藤らによるシステムや[15], Jipsenの仕事[16]が利用/応用可能であろう.また漢字における異体字や国字に対しての対応も検討していきたい.その他，記事へのグループ指定を筆頭としたやや煩雑な作業に対して，Ajax技術なども用いたユーザインタフェースの改善も今後の課題である.
4.3その他
現在,文書サーバと検印サーバは一対一で用意することを前提としているが,今後複数の文書サーバに対し、共通の検印サーバを利用することも考えられる.その際に,現在のスクリプトでは別々の秘密鍵で署名を行わせることや，また署名部のコピーを異なるサーバ別にフォルダを分けて保存することは出来ないため,改良の必要がある.記録の保存ということを考えると，現在のデータベースをベースとした記事管理はサーバに負担をかけてしまうと考えられる.そのため, DBMSは必要だが,それに全て埋め込むのではない，記事やユーザ情報の保存・管理方法が課題として上げられる.また，現在基盤となるシステムをRuby on Rails1.2.6で作成しているが，より柔軟な機能作成や今後蓄積されるデータの柔軟な活用を行っていくことを考慮すると, HTMLだけではなくXMLやJSONなどの複数のフォーマットでの出力も可能なRuby on Rails2.0への移行が望ましいと考えられる.そして、ユーザインタフェースとも関連するが、現在グループはシステムの利用者全体で共有し,ログインしている利用者であれば誰でも閲覧が可能で,ユーザであれば任意のグループに所属できるようになっている.しかし,現実にはグループの存在やそこに所属するメンバーを秘匿しておきたい場合も考えられる.それに関連して,ユーザの情報も現時点ではログインしている利用者であれば，誰でも閲覧が可能となっている．昨今個人情報の保護が問題とされる機会も多く,一般のSNSでも特定の知人のみにしか自分のユーザ情報を開示しない機能を持つものは多い*¹°.それらの問題も含め,今後情報の開示および管理の権限を誰にどの程度まで認めるのか検討を要する.
5終わりに
本研究では,研究記録などの管理を主目的とし,公開範囲を柔軟に制御可能かつ,記録の真正性および非改竄性を可能な限り保証し，検証の機能を持つシステムであるarχvesの構築を試みた.結果として,先に上げたとおりセキュリティやユーザインタフェース,またそのほかの面でも多くの課題はあるものの,一定の機能を持つシステムを実現できた.また,本システムにより,安価に, DVCSでもTAPでもない,電子書名つき電子文書管理の第三のあり方を実現できた.今後は,課題でも取り上げた本システムの問題点の対応や改良,そして蓄積されるデータの知的処理に関しても研究を進めたい. [1]原田篤史,西垣正勝,曽我正和,田窪昭夫, 「ライトワンス文書管理システム」,情報処理学会論文誌Vol.44, no.8, pp.2093-2105, 2003 [2]陳明強,吉川正俊, ｢時刻認証付きXML文書のデータベースによる管理について｣,電子情報通信学会第16回データ工学ワークシップ(DEWS2005), 5A-i10, 2005 [3]宇根正志,松本勉,「可用性および安全性の観点からみた各タイムスタンプ方式間の関係」,情報処理学会論文誌, vol.43, no.8, pp.2644-2658, 2002 [4]Toshiyuki Masui,  Satoru Takabayashi,  "Instant Group Communication with QuickML",   Proc. ACM Conference on Supporting Group Work(Group '03),  pp268-273,  2003 [5]江渡浩一郎,高林哲哲,増井俊之, 「quikWeb:メーリングリストとWikiを統合したコミュニケーション•システム」情報処理学会研究報告，2004-HI-111，pp. 5-11，2004. [6]永田周一，安村通晃,「Enzin:情報の公開範囲を手軽に変更できるコミュニケーションツール」,情報処理学会論文誌Vol.48, no.3, pp.1134-1143, 2007 [7]高井一輝，河口信夫，「ACS:多様な人間関係を表現可能なソーシャルネットワーキングシステム」情報処理学会論文誌，vol. 48，no. 7，pp. 2328-2339，2007. [8]高田良宏,笠原禎也,毛利信浩,松平拓也, ｢多様なアクセス制限に対応した自然科学データベースシステムの開発」,学術情報処理研究, no.11, pp.50-59, 2007 [9]C.Adams,  P.Dain,  D.Pinkas, R.Zuccherato, "Internet X.509 Public Key Infrastructure Time- Stamp Protocol(RFC3161)", ftp://ftp.rfc-editor.org/in-notes/rfc3161.txt [10]洲崎誠一,松本勉,「竜子署名アリバイ実現機構一ヒステリシス署名と履歴交差」,情報処理学会論文誌, vol.43, no.8, pp2381-2393, 2002 [11]山田竜也宮地充子,双紙正和, 「オープンネットワークにおける安全な暗号方式の更新に関する考察」情報処理学会論文誌  Vol.4,   No.8, pp 2102-2109, 2000 [12]宮崎邦彦,吉浦裕,岩村充,松本勉,佐々木良一, ｢第三者機関への依存度に基づく長期利用向け電子署名技術評価手法の提案」,情報処理学会論文, vol.44, no.8, pp1955-1969, 2003 [13]小森旭,花岡悟一郎,松浦幹太,須藤修, ｢署名鍵漏洩問題における竜子証拠生成技術について」,竜子情報通信学会「暗号と情報セキュリティシンポジウム」予行集, pp.983-988, 2003 [14]電子商取引推進協議会,認証・公証WG, 「電子署名文書長期保存に関するガイドライン」, 2002 [15]後藤洋信,坂本雅洋,江見圭司,「数式表示可能なウェブ上でのコミュニケーションシステムの構築」,情報処理学会研究報告2008-CE-94, pp1-8, 2008. [16]Peter Jipsen, "ASCII MathML", http://www1.chapman.edu/~jipsen/asciimath.html [17]黒田努,佐藤和人共著,株式会社オイアクス監修, 「基礎Ruby on Rails」,インプレスジャパン
1.インストール(1) Rubyのインストーラを入手する. http://rubyinstaller.rubyforge.org (RubyInstaller : One-Click Ruby Installer for Windows)ここでruby186-26.exe (数字部分は任意のバージョン)をダウンロード. (2)その後ダウンロードしたファイルをクリックし「実行」⇒「全てのコンポーネント」を選択して，インストールされるのを待つ.このとき, Gemも一緒にインストールされているはずなので,コマンドプロンプトで"gem -v"を入力し数字(バージョン)が出力されることを確認する. (3)RailsのインストールGemがインストールされていれば,コマンドプロンプトで下記のコマンドで最新のrailsがインストールされる. "gem install rails --include-dependencies" ＊特定のバージョンを指定してインストールする場合は"-v"または"--version"を付加して行う.コマンド例: gem install rails --version [バージョン] --include-dependencies gem install rails -y -v [バージョン] --include-dependencies (-v, --version:バージョンの指定, --include-dependencies:依存するライプラリも一緒にインストール, - y :インストール時の確認に全て"Yes"で) 2.Railsプロジェクトの作成メモ•バージョンを指定してプロジェクトを作成rails [プロジェクト名] _[バージョン] •Rails2.0以降でDBをMySQLに指定して作成するrails [プロジェクト名] -d mysql ("-d"は"--database"でも可) •利用しているプラグイン• ssl_required ¹ •プラグインインストールruby script/plugin install [プラグインのURL] 3.Gemのコマンド• gemの環境を確認gem env •インストールされてるrailsのバージョンの確認gem list rails標準でインストールされていないが，利用しているライプラリ• win32-open3   *12 •mongrel *13インストール方法： Gemがインストール済みであればrailsのインストール同様コマンドプロンプトで"gem install [ライプラリ名]" ○Mongrel + Apatch ( + SSL)の設定1.Apatch2.2以降をインストールする2.Apacheの設定ファイル(httpd.conf)の設定を行う1)必要なモジュールをロードするために,以下のコマンドのコメントアウトをはずすLoadModule proxy  module modules/mod  proxy.so LoadModule proxy  http  module modules/mod  proxy  http.so LoadModule rewrite  module modules/mod  rewrite.so LoadModule ssl_module modules/mod_ssl.so Include conf/extra/httpd-ssl.conf 2)バーチャルホストの設定<VirtualHost *:80> ServerName [プロジェクト名] DocumentRoot [アプリケーションのPublicディレクトリ] ErrorLog [エラーログの出力場所] <Directory "[プロジェクトのパス]\public"> Options FollowSymLinks AllowOverride all Order deny, allow Deny from all Allow from 127.0.0.1 192.168.0.0 </Directory> 3)フォアワードプロシキのOff ProxyRequests Off 4)静的コンテンツをApache側で処理するように記述ProxyPass /stylesheets/ ! ProxyPass /images/ ! ProxyPass /javascripts/ ! ProxyPass /*.html ! ProxyPass /favicon.ico ! 5)静的コンテンツのパターンにマッチしなかったリクエストをMongrelに転送するように指示するProxyPass（転送の基点）（転送先アプリケーションサーバのURL） 6)バーチャルホストの設定を閉じる</VirtualHost> 3.ApacheのSSL設定ファイル(httpd-ssl.conf)の設定を行う1)SSLの設定を以下のように書き換える<VirtualHostサーバのIPアドレス:443> SSLCertificateFile "※デジタル証明書パス" SSLCertificateKeyFile "※秘密鍵パス" ※デジタル証明書と秘密鍵の作成方法は後述2)バーチャルホストの設定2.の2)～5)の記述を同様に追加する. 4.Mongrelを起動して動作確認を行う. >mongrel_rails start -e development -p 3000 (Mongrelがインストールされている状態であれば"ruby script/server"でも上記と同様に実行可能) ○デジタル証明書と秘密鍵の作成方法1. Webサーバの秘密鍵の生成(鍵生成ディレクトリに移動) [/Apacheのconf以下:C:\Program Files\Apache Software Foundation\Apache2.2\conf\key] > openssl genrsa -des3 1024 > server.key genrsa  RSA形式の秘密鍵の作成. -des3  des3方式でファイルを暗号化. 1024  1024バイトの鍵を生成. 2.Webサーバの公開鍵の作成> openssl req -config ..\openSSL.cnf -new -key server.key > server.csr req : CSRファイルの作成します. -new：新規にCSRファイルを作成. -key鍵ファイル名：入力する秘密鍵のファイル名を指定(パスフレーズ付きの鍵の場合は,パスフレーズが必要) -config opensslのcnfファイル：openssl.cnfのパスを指定. 3.デジタル証明書の作成> openssl x509 -in server.csr -days 365 -req -signkey server.key > server.crt x509 : X.509形式のデジタル証明書の作成します. -in：CSRファイルパスを指定します. -days:日数証明書の有効期限を指定します. -req：入力ファイルがCSRファイルであることを指定します. -signkey：自己証明書生成時に使用するオプション.秘密鍵のパスを指定します.備考:秘密鍵のパスフレーズの解除方法(server.key⇒server.key_bk(ファイル名は任意)に変更後) > openssl rsa -in server.key_bk > server.key rsa : RSA方式の鍵作成. -in：CSRファイルパスを指定. ○その他メモ•ApacheのルートをRailsのプロジェクトのpublicフォルダに指定した場合(上記設定)のブラウザから「arχves」のTOPページへのアクセス方法は、”[ルートURL]/main”となる。例: http://localhost/main ※[ ]内の文字は全て環境に応じて任意の文字・教値を入れてください。参考文献高橋征義,諸橋恭介, 「Railsレシピプック183の技」,ソフトバンククリエイティブ, 2008/5/31 [Think IT]第７回: Apache+SSL環境を構築しよう！ (http://www.thinkit.co.jp/free/article/0706/3/7/)
書式: gpg [オプション] [ファイル]署名,検査,暗号化や復号,既定の操作は,入力データに依存
Helpに載っている以外で利用しているコマンド・オプション 利用例など
【設定】エンコード: UTF-8ストレージエンジン: InnoDBメモ： ●コマンドプロンプトでのDB確認を行う際, UTF-8であるため,日本語は文字化けを起こす.コマンドプロンプトでも日本語出力をする際は"chcp 65001"(UTF-8へのコードチェンジ)を行う. ●通常の設定では,いくらRails側でUTF-8で設定しても表示エラーが起こる場合がある.その場合は, my.cnfファイル(MySQLの設定ファイル)の[Client]以下に"default-character-set=utf8"以外にも，"character-set-server=utf8" (文字コードをUTF-8に指定)と"skip-character-set-client-handshake" (Clientによる自動文字コードセットをスキップする)を記述しておく. ※テーブルリスト•データベースの構成については次頁以降。
blog_kijis_groups blog_kiji_id group_id integer integer ·太文字はテーブル名・通常文字は外部キー ・点線は結合テーブル（多対多の関連付け用）
■ Controllerの構成/(ルート:/app/controllers) L_application.rb __blog kijis controller.rb └_comments controller.rb __groups_controller.rb _login controller.rb └_main_controller.rb _ (sign controller.rb* ¹ ⁴ ) __users controller.rb /account ⊥ blog category controller.rb L_blog_kijis_controller.rb L_groups_controller.rb L main  controller.rb /admin L base.rb L blog category controller.rb L blog_kijis_controller.rb L_ comments_controller.rb L groups  controller.rb L main  controller.rb L users_controller.rb .モジュール名はどのControllerでも共通で”Common”です。 .同名のcontrollerは同じデータを取り扱っているメソッドで、モジュールを共有しています。 .名称が異なっていますが、account/main_controllerは他のusers_controller同じデータを取り扱っている為、モジュールでメソッドを共有利用しています。 .作業内容の文頭に『★』がついているActionはサブルーチンです。 . Controller名の"controller.rb"は省略して記述しています。 . [trackback] [send_tb]は、それらしいものを作成してますが、実装はしてません。
modマーク説明* :モジュール化されてるAction
modマーク説明* :モジュール化されてるAction    〇:/同名のコントローラから呼び出し     ◎ : Account/同名のコントローラから呼び出し
modマーク説明* :モジュール化されてるAction    〇:/同名のコントローラから呼び出し     ◎ : Account/同名のコントローラから呼び出し
modマーク説明* :モジュール化されてるAction    〇:/同名のコントローラから呼び出し     ◎ : Account/同名のコントローラから呼び出し
Controller別Action一覧(5) modマーク説明* :モジュール化されてるAction    〇:/同名のコントローラから呼び出し     ◎ : Account/同名のコントローラから呼び出し
modマーク説明* :モジュール化されてるAction Controller別Action一覧(7)
modマーク説明* :モジュール化されてるAction    〇:/同名のコントローラから呼び出し     ◎ : Account/同名のコントローラから呼び出し
modマーク説明* :モジュール化されてるAction    〇:/同名のコントローラから呼び出し     ◎ : Account/同名のコントローラから呼び出しController別フィルター覧(2)
modマーク説明* :モジュール化されてるAction
/account
_acc_menu.rhtml _side_bar.rhtml
. “layout”フォルダにはメインフレーム(ページ構成の定義)が,”share”フォルダはコントローラ関係なく共有するファイルがまとめられています. "_(アンダーバー)"で始まっているファイル名は全て部分テンプレートです.基本的にAction名と対応したファイル名となっています. . . .フォルダの構成は，Controllersと同じです．（ただし，Viewがまったく存在しないControllerもあります．）
Controller別view対応表(3)
Controller別view対応表(4)
● Modelsについて。通常のデータアクセスのメソッドとvalidation (検証)のメソッドとは別表で記載しています。 。基本的にどのModelにも”JAPANESE_NAMES”というハッシュにカラム名をキーとして対応する日本語のカラム名を保存した変数が存在しています。 o “simple_text”はあくまでも見栄えの為に適当に作ったものなので、基本的に改行つきの長文の出力は"simple_format"の方をお勧めします。 ■Modelでのテーブル間のオプション設定について【Blogs.rb】 ○削除時に、対応するデータを削除⇒Blog_kijis, Categories ○Userへの外部キーをauthorに名称変更(通常user, user_id) ○削除時に、対応するデータを削除⇒Comments, TrackBacks, Materials検証用メソッドリスト
Model Helper一覧(1)
Model Helper一覧(2)
●検印サーバ側のプログラムは、DBを一切利用していない為、任意のプロジェクト名でRuby on Railsを作成後、以下のプログラムファイルのコピーとフォルダの作成で必要な動作が得られます。 1. /app/controllers/へ、sign_controller.rbをコピーする。 2.署名部分のコピーを保存するフォルダを作成しておく。 /public/sign/kiji /public/sign/material ……添付ファイルの署名部コピー保存フォルダ●茶付データや署名部の保存場所や一時ファイル名について■公開鍵ファイルのパスo    /public/keys/key[ユーザID].gpg ■署名部の出力ファイル名基本:#{path}#{mode}_#{filename} 1)記事署名部の保存パス/public/sign/kiji/kiji_sign[データID].txt 2)添付ファイル署名部の保存パス/public/sign/material/material  sign[データID].txt ■復号済み添付ファイルのダウンロード時。署名済みデータの保存場所○　public/material/Data[添付データID]_[記事ID]_[アップロードファイル名].txt ■ユーザ署名実行時の一時ファイル名o　sign[データID].txt Controller, Viewの一覧には記載していませんが, blog_kijiscontrollerに検証の改.竄の確認の取りやすさのために[edit (編集) ] actionを実装し，対応するviewも作成しています。実際の稼動の時には削除しておいてください。 ● GnuPGの公開鍵のファイル管理(アップロード)は出来ますが、登録作業は全て手動で行っています。また、登録されている鍵の管理は全てGnuPGで行われています。 ● 「プログリスト」の一覧表示時のアイコンは圖が添付ファイルあり圏が添付ファイル削除済み記事を示します。 (適当に作ったものなので、分かりにくければ変更して下さい）