OME never die! と言いたいけれど…

<a href=”http://msyk.net/ome”>OME</a>を一生懸命やっていたのは、1999〜2004年くらいかな。ちょうど、<a href=”http://msyk.net/cserver/mdo.html”>MDOnline</a>の頃に重なります。その後も、だましだましOMEを使ってきました。相当だましたので、OS X Lionでも使えてはいますが…。ちょっとかなりきつくなってきました。それでも、never dieと言いたいのですが、かなり苦しいかも(苦笑)。

まず、「再開」の機能により、ウインドウの残り方が今ひとつよくないのか、落ちることしょっちゅうです。まあ、データを書き込んでいないし、所詮テキストファイルなので悪影響はまったくありませんが、あまりいい感じではなく、特に、command+Wでアプリが落ちるのはちょっと面倒です。コンパイルしなおそうとしているのですが、これがなかなかやっかいで、まだうまく行っていません。そこはだましだましなところですね。

そして、ついにというか、やっと気づいたというか、11月11日を境にiCloudのメールの受信ができなくなっていました。できないのをやっと気づいたというのは、iPadでもメールを読んでいるからです。fetchmailコマンドでme.comのメールってなんでだめなんだろうか? 認証のエラーが発生します。

仕方ないので、Mail.appでiCloudメールを受けるようにしました。

そこでふと考えたのは、Mail.appをfetchmail代わりに使うことです。メールソースをAppleScriptで書き出して、メールの整理はOME側でやればいいじゃん!ってことで、近々に取り組むつもりです。

電子メールというきわめてレガシーな仕組みが今だ、同じように残ると同時に混沌さは年々増す感じもします。昔から、電話をいちいち録音していないのと同じように、メールだって、しばらくすると「捨て」でいいとも思ったりもしますが、なぜ、テキストファイルで残したいのかというモチベーションを思い出し、もうひと頑張りしようと思います。つまり、OMEはメールの整理・ストレージに移行するということです。

さて、どうなることやら。

[IM]RSAを使って、JavaScriptで暗号化し、PHPで復号する

表題の通りの仕組みを、INTER-Mediatorに組み込もうとして、2日ほどもがきました。RSAつまり秘密鍵と公開鍵を使った暗号化をフレームワークに組み込み、クライアントで入力したパスワードを、暗号化してサーバに送るという仕組みを組み込んでいます。普通パスワードはハッシュだろうと思われるかもしれませんが、フレームワークが認証するパスワードではなく、パスワードをデータベースエンジンへのアクセスに使うべく、クライアントで入力したものをバックエンドまで安全に到達させるための暗号化なのです。

RSAやハッシュ関連のことは、ネイティブな開発ならOpenSSLを使えばおおむねOKなので、同じようにライブラリを集めれば楽勝だろうと思っていました。また、PHPにはopensslライブラリがあるので、まあ、なんとかなるだろうと思いました。要件としては、キーの指定を簡単にするということ。つまり、公開鍵と秘密鍵が1つもPEM形式で得られれば、それを設定ファイルに書き込むことでキーの指定ができるということです。もちろん、生成は「openssl rsagen 1024」みたいなコマンドで簡単に済ませたいわけです。

JavaScriptの世界では、Dave Shapiroさんが作っているライブラリがあり、後々のいくつかのライブラリの多くはこれを改良しています。DaveさんのはPEM形式でキーを与えられないので、Tom WoさんのCrypticoが作られたようで、さらに別の人が署名までできるようにしています。Crypticoでいろいろやっていたのですが、うまくいかない…というか、単純にこのライブラリの問題ではなく、PHPのライブラリとの組み合わせの問題があったのです。

それで、PHPの方はというと、openssl関連関数があるので大丈夫かと思っていたら、これがなかなかうまくいかいないのです。まず、PEMでキーを与えるのが原則とすれば、Crypticoを使ってクライアント側で暗号化するのが手軽です。それを、PHPのopensslの関数で復号するのがどうしてもうまくいかないのです。そのあたりのドキュメントが今ひとつ詳しく書いておらず、コメントには「マニュアルは正しくない…」などと書いてある始末で、あれこれやってもだめでした。

ただし、PHPのopensslの関数を使えば、PEMの鍵データから、RSAの本来の鍵というか、計算式に出てくる鍵の数値をそのまま得られる事がわかりました。さらに、RSA: Encrypting in JavaScript and Decrypting in PHPというドンピシャなものがあったのですが、それはDave Shapiroさんのライブラリを使っていて、RSAの本来の鍵を使う方法が記載されています。ところが、このサイトに書いてあるPHPのライブラリはpearにあるCrypt_RSAで、説明に使っているものはすでのメンテナンスがなされていません。それを使う手もありますが、メンテナンスされているライブラリの方がいいかと思い新しいサイトへのリンクを見ると、なんとこれが、以前このblogでも紹介したPHPだけで作られたSSHのライブラリを含むphpseclib:に移行していたのです。SSHのライブラリはきわめて順調に動いたので期待をして、こちらのRSAを使って復号しようとしました。しかしながら、どんなにこねくり回してもだめなのです。このライブラリのサポートのBBSにあるこの書き込みと同じ場所でエラーが出ているようです。Macだとだめで、debianだと動くようなことが書かれているのが気になるところですが、この方法でうまく流すには簡単には行きそうにありません。

Dave Shapiroさんのライブラリで暗号復号するのはできます。また、phpseclib:で暗号復号はできます。つまり、異なるライブラリをまたいでの暗号復号がうまくいかないのです。Dave Shapiroさんのライブラリで暗号化したものを、opensslコマンドで復号してみると、パディングに関するエラーが出て復号できません。データ形式の微妙な違いがあるのでしょうか? ドキュメンテーションの薄いライブラリや、あまりカスタマイズできないライブラリということで、これ以上手を下すことができず、ここで行き詰まってしまいました。

それで、改めてググって必死に探した結果、見つけたのがbi2phpというライブラリで、しかもMIT Licenseです。JavaScriptのライブラリは、Daveさんのものに独自に改良したものだそうです。それと互換でPHPのクラスを作ったというところでしょうか。いずれも、RSAの本来の鍵を指定するのですが、「データは全部HEX」というように、ある意味非常にわかりやすく、さくっとうまく行きました。

ということで、わかった事をまとめておきます。RSAの秘密鍵、公開鍵という仕組みはもういいとして、そこで使う鍵は、たとえば「openssl genrsa 1024」というコマンド入力で作られます。そのデータはPEMという1つのテキスト列であり、いわば、そこに秘密鍵と公開鍵などなど、RSA暗号処理に必要なデータがPKCSのルールに従ってパックされたものです。

$ openssl genrsa 1024
Generating RSA private key, 1024 bit long modulus ...................++++++ ............++++++ e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQC/BlONnPUfSc95YmrcOUV0IbmeBZvibbAssetKBXAG0DGeKzc7        : 2MgfcIZ3C7lf0+yx3/RhXwJBAIYHkht7UPSpPeTvPzc4v89yBlkkGeN9xLbdONT3 uzINAQkGvVmDhNLYqxkgDysBUy/Q2f41DenUZJfEFLQBs5w= -----END RSA PRIVATE KEY-----

PHP側では、このPEM形式の文字列を使って、以下のプログラムで、RSAの計算に使うキーを求めることができます。$generatedPrivateKeyにはPEM形式のキーの文字列、圧縮アルゴリズムがAESの場合はパスフレーズを入れるので、その場合は$passPhraseに指定しますが、パスフレーズが設定されていない鍵は2つ目の引数は適当に無視します。

$res = openssl_pkey_get_private( $generatedPrivateKey, $passPhrase );
$keyArray = openssl_pkey_get_details($res);

この、$keyArrayの配列にいろいろなものが入っていて、公開鍵だけを取り出すには、$keyArray[‘key’]とします。

Daveさんのライブラリを使うには、鍵のオブジェクトを作成しますが、当然、自分で生成するのではなく、このPEMを鍵としてオブジェクトを初期化します。初期化関数部分は、次のように定義されています。biRSAKeyPairが鍵のクラス名と考えていいでしょう。

function biRSAKeyPair(encryptionExponent, decryptionExponent, modulus)

ここで、encryptionExponentは$keyArray[‘rsa’][‘e’]、decryptionExponentは$keyArray[‘rsa’][‘d’]、modulusは$keyArray[‘rsa’][‘n’]から得られます。生成した鍵からopensslのコマンドを使って出力(例えば、openssl rsa -text -in gen.key)した結果を見ながら、対応付けを確認しました。配列から得られた結果はバイナリなので、PHPの場合、bin2hex関数を使って16進文字列にして、JavaScript側の引数に指定をします。2次元目のeとdは、encrypt、decryptなんでしょうね。

なお、INTER-Mediatorでは、JavaScript側では暗号化しかしないので、2番目の引数は指定しません。というか、指定してクライアント側で見えたらいけません。なぜなら、$keyArray[‘rsa’][‘d’]は秘密鍵であり、暗号化には使わないからです。いずれにしても、JavaScriptのプログラムをサーバ側のPHPで生成してクライアントに送り込むという部分がこうした処理を組み合わせて作る事ができます。

bi2phpのPHP側のクラスは、JavaScriptとほぼ同様なプログラムでいいようになっており、サンプルのHTMLを見ればプログラムの作り方はすぐにわかると思います。非常に紆余曲折がありましたが、JavaScriptとPHPの双方で暗号復号をするには、bi2phpというライブラリでOKということです。ただし、PHPのopenssl関数を使って、PEMから鍵の値を得たりということは処理として必要になるということです。このライブラリをまとめたAndrey Ovcharenkoさんに感謝するともに、ライブラリをここまで育て上げたみなさんに感謝します。

消費税増税で忘れられていること

消費税が5%から8%、そして将来は10%になるという法案が政府によって進められています。現在、年間12兆円の消費税収入があるらしいのですが、いろいろな議論が巻き起こっているのも周知の通りです。その中でまったく議論が出てこないのが「免税業者」についての話です。

現在は、すべての取引(ただし非課税のものをのぞく)に消費税の徴収が義務とされているはずです。私は2005〜2008年は会社員だったのですが、その期間の前は、「あなたは免税業者ですか」と聞かれてから請求金額が決まるという会社が多かったことが思い出されます。免税業者なら5%付加しない金額で請求書を書き、その金額が払われてたのですが、会社員をやめてフリーになって改めて調べると、免税業者に対する支払いでも消費税を付加するのが必要という記述を税務署のサイトなんかで見つけました。世の中わかりやすくなったものです。会社員以前の消費税話もいろいろあるのですが、今現在の話をしましょう。

では、現在、免税業者になっている個人や法人はその付加された5%をどうしているかというと、単にその人や法人の収入になっています。免除されているので国に対して払う必要がなく、収入なわけです。つまり、借受消費税は単に収入としてあつかっていいことになっています。現在、免税業者としてメジャーなのは年間で1000万円以下の収入のある業者です。それから、会社設立してからの一定期間も免税業者です。零細企業の支援の側面もあるのかもしれませんが、比較的多いと思われるのが、サラリーマンをしながら副業でちょこっと儲けているような人も、その副業部分が免税業者扱いになっているのが多いのではないでしょうか。これは統計がないのでわかりませんが、会社員しながら1000万を超える売り上げがある人はかなりの強者であり、その方は副業でも課税業者になりますね。まあ、普通はそこまでかせげないでしょう。

2001年頃に、免税業者の基準が売り上げ3000万円から1000万円に引き下げられました。免税業者数は368万人から231万人になり、免税業者は全体の40%になるという数字が発表されています。それまでは消費税を払っていない業者の方が数で多いという結果だったのです。当時は「うちは株式会社ですから」みたいな理由で課税業者を名乗っていた人もいましたが、おかしな理屈であり、都市伝説としか言いようがなかったですね。まあ、それはいいでしょう。

私は、1000万円以下という免税業者という施策自体を再検討する必要があると考えます。税金の公平な負担という原則があるのなら、収入に関係なくルールに従って支払うべきです。消費税は、収益に正比例するきわめて公正な税金です。消費者にはあますところなく支払わせるのなら、業者も同様じゃないでしょうか。全業者の支払い義務があるとした上で、優遇措置を検討するべきです。

収入を500万円、そしてさらに中間の250万円を平均的な収益としたら、精算した支払い税額はその5%として12.5万円です。非課税業者が200万人としたら、2500億円となります。全体の税収12兆円の中でみれば少ないのですが、それでも2%程度の増収となります。もちろん、収入額の平均値はもっと少ないとも言えますが、でかくもなく、少なくもない規模ではないかと思います。ただ、徴収のための手間というか、経費が増えるとも言えるのですが、簡易的な計算方法を導入しつつ、オンライン化により、さほどの費用はかからないと思います。

大昔の3000万円のライン、1000万円のライン、いずれも「政治的な判断」とされていて、確固たる基準がありません。これを撤廃すると、必ず「零細企業を苦しめるのか」的な意見が出てきますが、苦しめているのではありません。本来、消費者が国に対して払ったと思っているお金を、自分のところにとどめないようにしましょうというだけのことです。本来の収入ではないものを「自分のもの」として扱うフィーリングが正しくありません。そして、少なくとも、サラリーマンの副収入、つまり生活の糧は本業の給料で得られている人にまで非課税を適用するという点は、過剰な優遇としか言いようがありません。

税の公平は絶対に守られていないといけないと思います。増税の話題で免税業者のことが出てこないことに、やっぱりどこか「選挙対策」が見え隠れしている気がします。

「気付き」という言葉について考えてみた

最近というか、ここ4、5年前から「気付き」という言葉がよく使われます。古い人間として、やや違和感があり、自分ではあまり使わない言葉ですが、やっぱり気持ち悪いと思う人もいるようです。

当然ながら、気付くは動詞、気付きは名詞です。しかしながら、気付きは「気付いた事」という以上に、自分自身がその事柄を所有している意識が強い単語と考えます。つまり、気付いた上でその背景を理解し、その事柄を別のことにも活かせるという意味を示すために使われているのではないでしょうか。しかしながら、気付いて、理解して、解釈してということもみんな動詞です。動詞って単なるプロセス的にとらえられることもよくあります。「早く起きるのは大変です」「起きるのは当たり前だろう」、つまり、起きて会社に行くのは当然というプロセスの中の動作が「早く起きる」ことなのです。一方「早起きは大変です」となるとどうでしょう。やっぱり「当たり前だろう」と思うかもしれませんが、「早く起きること」自体が成果になっているニュアンスが若干あります。うがった見方をすれば、「早起きして遅刻しないで出社できたという成果があった」という心理があるのではないでしょうか。

つまり、何かが起これば「気付く」のは当たり前だし、そういう状況になったら誰でもできるだろう、やるだろうという考えがあります。一方「気付き」というのは、その人が気付き理解したという成果を強調していることなのです。何でも成果を求められる昨今、イメージとして成果っぽい言葉が頻繁に使われるのはよくわかります。

しかしながら、この「気付き」は自分の成果だけでなく、自分が所属する組織に対する貢献を、暗黙に示す言葉でもあると考えます。お店に注文したとき、商品がないとき、「お取り寄せましょうか」と聞かれますが、「お取り置きしましょうか」という言い方もよく言われます。前者は、お客の注文だから仕入れるのは当然というニュアンスもありますが、後者はお店として顧客の要望に応えましたという成果の強調が感じられます。名詞化することで、自分の成果となり、組織の成果となる。そうなれば、言葉は自然に根付き、となるわけです。

さらに、動詞は続きを求めます。「お客様のお言葉に気付きました」「で、何を気付いたの?それでどうしたの?」となります。ところが「お客様のお言葉に気付きがありました」となると、もちろん、それはどうなのと聞きたくなりますが、何となく完結感漂う言い方となり、あまり突っ込めない雰囲気を作っています。よく、「悟る」と「悟り」が引き合いにだされますが、「悟り」と言ってしまえばそれ以上突っ込めません。「気付き」と言ってしまう事で、ある種の遮断、つまり言葉のやり取りの遮断が発生します。何かを報告するときになるべく上司に突っ込まれないようにしたいという気持ちが「気付き」という言葉を引き出すのかもしれません。

気付きという言葉に違和感があるとしたら、そのときのコンテキスト(文脈)において、成果を暗黙的に強調しているからだと考えました。その上で、深堀を暗黙に否認する感覚を聞いた人にもたらします。本来は、気付くことによって、他のことに応用できるわけですが、気付きだけを強調すると、本当に応用しているのかという疑問も湧きます。そして、応用できないのなら、ほんとに気付いているのかという疑問にもつながります。そして、その確認を遮断するのです。少なくとも「気付き」は悪い言葉ではありませんが、その結果、何ができるのか、何ができたのかを同時に伝えることで、違和感はなくなるのではないでしょうか。

JavaScriptのeventではまる

キーコードを取るkeyCodeや、シフトキーを押しているかどうかを確かめるshiftKeyというプロパティが「event」で使えることになっている。そこで、

document.onkeydown = function(e) { .. }

とすれば、常にキーを押したことを拾えるが、この場合は仮引数eがイベントを参照しており、e.keyCodeでキーコードが拾える。

ところが、次のように、onclickに関数を書いた場合、ブラウザ間の非互換性が発生する。

function clickThis(target) { … }
:
<div onclick=”clickThis(this)”></div>

clickThis関数内で「event.keyCode」と書いて動いてると思っていたら、Firefoxのみうまく動かなかった。つまり、eventというキーワードで、直前のイベントを取得するのはFirefoxではできなかったということである。Safariではできた。

しかしながら、以下のようにすると、Firefoxでも稼働した。関数clickThis内部では、ev.keyCodeなどによってイベントのプロパティに参照する。

function clickThis( target, ev ) { … }
:
<div onclick=”clickThis( this, event)”></div>

つまり、Firefoxでは、「event」によって、直前のイベントを参照できるのはローカルな範囲だけということになる。他のブラウザで、「event」という記述が使えるのは「window.event」というウインドウに直前のイベントを参照できるプロパティが存在しているからである。Firefoxにはそういうプロパティは存在しないが、JavaScriptの規約では存在しないので正しいらしい。

[IM]INTER-Mediatorの認証フレームワーク(2)

少し前に書いた記事「INTER-Mediatorの認証フレームワーク」でのプロトコルでは、中間者攻撃に弱いのが分かったので、最初に1回やりとりを増やしました。

cd573

こうすれば、中間者が得られるデータは、un、ch、h(ch, h(pw))となります。しかしながら、正しいリクエストでは、h(ch, h(pw))の計算におけるh(pw)つまりパスワードにハッシュをかけたデータが必ず必要になります。中間者はそれを持っていないので、正しいリクエストを生成できません。(当然ですが、ハッシュなので、h(ch, h(pw))からその計算の元になっているh(pw)は求められないという前提があります)

また、チャレンジは毎回異なる(確率的に同一である可能性は0とみなせる)とすれば、毎回チャレンジの値が変わり、「以前と同じチャレンジが生成されるまで待つ」という手段もとれなくなります。また、毎回チャレンジが変わることで、同じ通信内容でも生成したデータが異なることになり、過去のデータをため込むことでの一致を見つける手法もほとんど役に立たないと思われます。

これで、クライアントとサーバの間の通信経路のセキュリティはとりあえずクリアできたとします。

アプリケーションの実行する上では、クライアントのJavaScriptはある意味、プログラムを勝手に実行されて変数の値などを取り出されたり設定できる可能性があります。その状態で懸念されるのは、他人への成り済ましです。自分のアカウントでログインをした後、javascript:…でユーザ名の変数を書き換えて、アクセスが成立すると問題です。特にその方法で他人に成り済ますのは重大なセキュリティの問題になります。

上記の方法では、仮にユーザ名を変えることができても、チャレンジとユーザは対応関係があるため、ユーザ名の変更をしてしまった後では必ず認証エラーが出るはずです。

開発者が意図したテーブル以外にアクセスできるか…ですが、データベースのアカウントはサーバから移動しないので(ただし、デバッグモードで見える事もある)クライアントで参照はできない。つまり、データベースの直接続は無理です。リクエストのテーブル名を変更する事もできません。定義ファイルに記述したテーブルとそれへのアクセスしかできないので、たとえば、一般には見せていないユーザ管理テーブルを参照することも不可能です。

さて、また、少し塩漬けします(笑)。

[IM]INTER-Mediatorの認証フレームワーク

INTER-Mediatorはだいぶんと実用的になってきました。そろそろ、先のアーキテクチャを考えはじめています。認証のフレームワークをどうするか、いろいろ考えています。要は、AJAXでの認証となると、単にHTTPでの処理と同じという情報しか得られませんでした。それでもいいのですが、Webアプリケーションでの苦労をもう一度行うことになります。認証は確かにできるのですけど、その後、アクセス権の管理をアプリケーションに組み込まないといけません。たとえば、ユーザごとに参照できるレコードが決まっている場合、認証結果からクエリのパラメータを調整するなどの処理が必要になります。下手をすると、ユーザ名をうまく切り替えたら他人になってしまえるようなものになってしまいかねません。

つまり、認証とアクセス制御をフレームワークで処理をすることによって、アプリケーション作成の上で、安全確実に認証をすることを考えたいと思いました。

とは言え、独自にプロトコルを組むというのも大変な話です。ここで、AWSのやり方をヒントにして、ハッシュをリクエストに入れて認証をするという方式を利用してみることにします。

前提は、データベースがあって、ユーザ、ハッシュしたパスワード、チャレンジ、チャレンジの発行タイムスタンプを持つテーブルを利用するとします。これらはフィールド名は決め打ちにしてしまうつもりですが、他のフィールドは自由に作成できます。その上で、以下のようなシーケンスを考えてみました。h( ) はハッシュを求める関数のつもりです。48623

現在、テーブルは自由に利用できますが、たとえば “security” という属性を作り、そこにフィールド名を記述すると、そのフィールド名に、ユーザ名と同じデータしか取り出さないようにするという仕組みにしたいと思います。たとえば、personテーブルがあれば、

“name”=>”person”,
“security”=>”accessibleusername”,…

のように定義ファイルを作ります。WHERE句で、accessibleusername = ユーザ名、という条件を常に付ければいいかと思います。なお、”security” 属性をたとえば、”__im_authonly” にすると、認証が通ればすべてのデータを参照できるといったような仕組みも入れておこうかと思っています。

あと、ユーザデータベースの保護についても考えないといけませんね。まあ、でも、定義ファイルにあるテーブルしか処理できないという仕組みを徹底させればいいのかなと思ったりします。何か穴があれば、ぜひともご指摘ください。

計画停電サイトtden.me運営者の意見

計画停電検索サイトtden.me (msyk.net/blackout) 運営者としての見解を記載しておきます。

2011年3月11日に発生した東日本大震災により、電力供給元の福島の原子力発電所が大きな被害を受け、発電できなくなるという事以上に放射能を自然界に放出してしまったという最悪の事態にまでなっていることはみなさんがよくご存知のことです。震災直後より、東京電力では「計画停電」(当初は輪番停電)として、電力供給不足に対処してきました。私の住んでいる地域は何度も計画停電による停電が発生し、うち、何回かは夜の停電でした。もちろん、さまざまな不便はありますが、状況を考えれば仕方ないと考えていました。

計画停電が実際に実際されたのは概ね3月中です。4月以降、電力需要が下がることもあってか停電は実施されていません。しかしながら、夏の電力需要が高まる時期に、停電が起るかもしれないということで、東京電力よりさまざまなアクションがなされています。節電の呼びかけと同時にどうしても供給が足りない場合には計画に従った停電を行うというものです。

こうした東京電力の姿勢について「原子力発電の必要性を暗黙に理解させるための茶番である」といった批判がメディアを中心にしてなされています。「計画停電検索サイト」はそうなると、東京電力のそうしたプロバガンダに協力するものかと思われるかもしれません。

しかしながら、当サイトの管理者として、東京電力の原発プロモーションに協力するものではないことを強く主張します。停電といった今まではほとんど起らなかったことがまさに目の前で起こり、今後も起ろうとしています。避けられないことなのであれば、その情報を提供することによって、事前になるべく知っておくということが非常に重要なことだと考えます。極端に言えば、停電も私たち生活者にとっては一種の災害です。しかしながら、それを知っておく事で、食事の時間をずらすとか、コンピュータを終了しておいたりといったことができるわけです。計画停電に賛同するわけではありません。そうではなく、発生する不便に対する対処をするための情報提供をしたいということです。

原子力発電所については、政府や関係機関は、口を揃えて「安全だ」と言ってきました。すでにそれは嘘だったことが明るみになっています。以前より、私は「安全なら大手町や永田町に原発を作るべきだ」と言ってましたが、今やそれはジョークにもならない状況です。おそらく危険だからという理由で都会から遠く離れたところに作ったのでしょうけども、大事故のために広い範囲に被害が及び、発達した流通網によってその影響は遠方にも及ぶのです。CO2の排出の問題は大きいですが、もっと重要なことは放射能を排出しないことであり、今、放射能が自然界に大量に放出されている事実を認識しなければなりません。

停電は不便ですし、いろいろやっかいないことばかりです。しかしながら、停電が起こりまた取りざたされるということから、放射能を大量に排出するという自然環境のみならず人間社会の破壊が進んでいることを強く意識せざるを得ません。それは人間社会で起った小さな失敗が積み重なったものでもあるわけです。停電によってそのことを多くの人がより強く意識し、どうすれば復旧できるのかということを意識する契機になることを願います。

Appleテクノロジーの5年周期

今日の未明に、次期Mac OS X Lionが発表されました。巷ではAirの方に注目が集まっているようですが、Lionの方がこの世界で仕事をしている者にとってはマジなネタです。

2011年、Mac OS X Lionがリリースされるわけですが、大きなポイントは、iOSのエクスペリエンスの統合です。これは、新たなOSが出てくる事に匹敵する程の変化と思われます。しかも、来年夏のアップデートを今からアナウンスするというのは、開発者のアダプテーションが必要だからと考えられます。ということは、単なる見栄えの違い以外にもさまざまな根本的な変化があるのではないかと思われます。

そのように予想するのは、Appleのテクノロジー的な大きな変化は、5年周期のサイクルがあると考えられるからです。Mac OS Xのリリースは、2001年です。Macを取り巻くここからの流れを見ると、アップデートが続き、それぞれ特筆すべき点は多々ありますが、次のジャンプは2006年からのIntel CPU搭載です。1年以内にすべてのラインナップがPowerPCからIntelに切り替わりました。そこまでちょうど5年、そして次の5年目が2011年です。2011年に発生する大イベントは「Mac OS X Lion」であることはもはや疑いのないこと…と考えられませんでしょうか?

一方、iPod〜iOSへの流れを見てみます。デバイスうんぬんについては5年周期はあまり見えないですが、iTunes Music Storeが2003年、App Storeが2008年です。オンラインとの連携がビジネスのキーであるAppleの携帯デバイスなので、ここの5年周期は意味深な気もします。iPodは2001年ですが、2006年にはApple TVが出ています。ここはちょっと判別しにくいのですが、初期のApple TVは「OS X」なるOSが搭載されていました。iPodについては諸説有りAppleの発表がないのでOSは判断しにくいのですが、携帯デバイスのインターナルな世界では、2001年からの初期のOS、そして2006年からのMac OS X系列のOSへと5年周期で変化しています。

90年代にもこうした周期があるのかどうかですが、1996年末に事実上NEXTSTEPを次期OSとして決定していて、そこから5年の2001年に正式リリースになっています。68kからPowerPCへの移行は1993年、そして1998年にはiMacの登場ということもあります。

いろいろなエポックメイキングなAppleのテクノロジーの変化を見る限りは、5年周期は至る所で見られます。従って、Mac OS X Lionは大きな変化をもたらすマイルストーンと考えられます。現状、発表された内容は、エクスペリエンスのiOS化であり、Mac版のApp Storeの開始ということもありますが、きっと全貌はこれだけではないでしょう。こんな次期に発表するだけに、今後デベロッパーが対処しないといけないような何かがあって、機密ベースで少しずつ公開されるものと思われます。そして、2011のWWDCで全貌を明らかにし、夏の発売でいきなりブレーク!というのがAppleのシナリオのような気がします。

ということで、想像ですが、iOSとMac OS Xの違いがかなりなくなるのではないかと考えられます。もともと主要なフレームワークはかなり近いのですが、それを可能な限り近づけるということです。Mac OS Xは高機能ながら複雑で巨大なOSでもあります。そのための使い勝手の悪さや管理の大変さもあるわけです。現在のCocoa Touchのフレームワークで作ったアプリケーションがMacでも動くように拡張をしつつ、Macの側ではファイルというものを意識しないでもいいくらいにまで、iOS的な操作体系になるのではないかと予想されます。

DHCPセキュリティ弱い説:続編

先日、このブログに、「DHCPはセキュリティが低い!?」を書いたところ、けっこう反応がありました。現状、「セキュリティが弱い」というコンセンサスがないにもかかわらず、固定IPで運用しているという場面は決してない訳ではないということで、Twitterでもレスポンスをいただきました。

しかし、そんな情報がどこから出て来たのだろうかとふと疑問に思い、いろいろ検索をしてみました。まずは、マイクロソフトの「DHCPのセキュリティ情報」です。最初に『DHCP と関連プロトコルでは、次のようなセキュリティ上の問題が判明しています。』と前置きをして、以下のようなことが記載されています。タイトルだけ抜粋します。

  1. DHCP が認証されていないプロトコルです。
  2. DNS サーバーに対するサービス拒否攻撃を、DHCP サーバーを介して実行できます。
  3. 承認されていない Microsoft 以外の DHCP サーバーが DHCP クライアントに IP アドレスをリースできます。

1の認証を経ないプロトコルであるというのはその通りです。ただし、認証を行う方法はあります。これは後で説明をします。2については、一般的なDHCPの問題ではなく、ホスト名とIPアドレスの対応をActive Directoryにレコードとして追加するダイナミックDNS特有のセキュリティ問題です。一般のDHCPには関係ありません。3についてはADに承認したDHCPという仕組みを利用できますが、当然ながらADとは関係ないDHCPを立てる事は可能なのです。文章を読むと、別に誤解をさせることは何も書いていません。しかしながら、前置きのところだけを見て、それだけで判断してしまう人もいるんじゃないでしょうか。

日本の学会誌についても、検索してみました。たとえば、「IPアドレス自動割り当て方式(DHCP)におけるセキュリティの実現方法」網淳子, 岡本利夫(1995年電子情報通信学会総合大会 B-829)という論文があります。この論文は、認証なしにIPアドレス配給ができるDHCPのニセモノサーバの存在を検知する方法を提案しています。その部分を引用すると『ところが、現状のDHCPはセキュリティの面で不充分であり、権限のないサーバーが勝手に立ち上がって誤ったアドレスや経路の情報を流したり、悪いホストが他のホストになりすまして情報の横取りをする可能性が高い。』となっています。省略すると「DHCPはセキュリティ面で十分じゃない」となるかもしれませんが、この論文はニセサーバの問題を論じているのです。固定IPで運用するべきとはどこにも書いていません。

他に見つかったのは「特集 モバイルコンピューティングを支えるシステム技術/移動透過な通信を実現するプロトコル(寺岡文男)」(電子情報通信学会誌 Vol.80 No.4 pp.344-349)というものがあり、ABSTRACTの引用をすると『DHCPはネットワークパラメータの自動設定を行うプロトコルである。Windowsにも実装されて広く利用されているが、認証の機構がなく、セキュリティに問題がある。』と書かれています。この記事では場所を移動する状況での通信方式についてのことが書かれていますが、DHCPのセキュリティについて論じたものではありません。認証をしないという仕組みについての喚起として記載されています。

いずれも間違えたことはもちろん書いていません。しかしながら、断片的に読んで結論を出してしまう人にかかれば、「DHCPはセキュリティ的に問題がある」ということになってしまいます。

ちなみに、現在において、DHCPの認証はできるかどうかというと、「簡単に」できます。1つはDHCPサーバに応答してもいいホストのMACアドレスを登録する方法です。ワイヤレスでも使われる場合もあります。使うPCのMACアドレスを逐一設定しないといけないので、管理の手間はかかりますが、確実な方法として使われています。ただ、MACアドレスの登録なんてどうやるの?と思う方もいらっしゃるでしょうけど、現在はいちばん安物のブロードバンドルータでも、管理ページを開けばこの設定は出てくるのじゃないでしょうか。サーバOSでのDHCPでは設定できて当然です。この機能が使えないという状況は、実際には皆無に等しいでしょう。

さらにより確実な方法として、802.1Xという手法があります。ただし、認証のためのサーバの設置や、場合によってはデジタル証明書の発行などの作業が必要になり、簡単には行きません。しかしながら、高いレベルのセキュリティを使うところでは利用されているソリューションです。

では、認証をしないDHCPで、どんな工夫があるのかも紹介しましょう。会社などでは、カードキーで社員証にもなっているカードをリーダに読み込ませないと、オフィスに入れない環境ならば、「オフィスにいるのは社員あるいは承認された人である」という理屈が成り立ちます。それがほぼ100%実現されるのであれば、認証をしないDHCPでも問題はないでしょう。

カードキーがないようなところでも、前に書いたように、普通は基本的なセキュリティ、つまりよそ者が簡単には入れないようになっているので、概ね問題ないと考えるのが一般的です。よそ者がネットに簡単につなげるようなところでは、ネットワーク以前に財布や家具がなくなります。また、検索して見つけた記事で「我が家のインターネットはDHCPではセキュリティ的にまずいでしょうか」という答えに「ネットの心配をする前にまずは鍵を直しましょう」という回答がありましたが、まさにその通りですね。

DHCP危険説は一種の都市伝説かもしれません。もちろん、プロトコル的な問題点はあるのですが、これまでにも説明してきたように、それらの問題点は実際には問題にはなっていませんし、認証をさせるという解決策もあります。おかしな伝説がまことしやかに流れることがないように願う次第です。