セキュリティで保護された Windows Mobile 開発と導入

  • [アーティクル]

August, 2004

Microsoft Chung Webster

適用対象

Microsoft® Windows Mobile™ 2003-based Pocket PC

Microsoft Windows Mobile 2003-based Smartphone

Microsoft Exchange 2003

Microsoft eMbedded Visual C++® 4.0

Microsoft .NET Compact Framework 1.0

Microsoft SQL Server™ CE 2.0

Microsoft Windows® CE .NET 4.2

概要 : こ の記事では、Pocket PC と Smartphone に利用できる開発 / 導入セキュリティのオプションについて説明します。これには、公開鍵インフラストラクチャ、Exchange Server を利用した電子メール、仮想私設網 (VPN)、WiFi、端末 コンフィギュレーション管理、Pocket PC 起動パスワード、SQL SE セキュリティなどがあります。

マイクロソフト ダウンロード センターから Secure Windows Mobile Development and Deployment.msi をダウンロードしてください。

トピック

はじめに はじめに
モバイルに対する脅威 モバイルに対する脅威
公開鍵インフラストラクチャ 公開鍵インフラストラクチャ
Exchange Server と SSL による電子メール Exchange Server と SSL による電子メール
仮想私設ネットワーキング 仮想私設ネットワーキング
より安全な WiFi より安全な WiFi
標準の境界セキュリティ 標準の境界セキュリティ
Pocket PC のカスタム パスワードによる境界セキュリティ Pocket PC のカスタム パスワードによる境界セキュリティ
Smartphone アプリケーション セキュリティ Smartphone アプリケーション セキュリティ
XML による端末管理 XML による端末管理
File System Filter を使用したカスタムな記憶域 File System Filter を使用したカスタムな記憶域
SQL Server CE セキュリティ SQL Server CE セキュリティ
最後に 最後に

はじめに

導 入とは正確に何を指すのでしょうか。ハードウェアとソフトウェアなど様々な状態が含まれますが、第一に展開とメンテナンスが挙げられます。デスクトップと サーバの世界ではメンテナンスが導入計画の一要因となる中で、Microsoft® Windows Mobile™ 2003 ベースの Pocket PC と Microsoft® Windows Mobile™ 2003 ベースの Smartphone は、導入とメンテナンスの最先端とは言い難くなりつつあります。この記事では、ハードウェアの導入とメンテナンスに役立つよう、端末の設定作業などを支援 する様々な技術を説明します。また、実際に使用中のアプリケーションと端末上のデータのセキュリティを向上できる開発技術も説明していきます。

モバイルに対する脅威

ス マートクライアントアプリケーションの設計開始時に、ご自分の資産、脅威、リスクを見極めるために脅威モデル分析を行うべきです。これらには、端末上での データアクセスのセキュリティ保護、および端末と遠隔端末間通信のセキュリティ保護が共通して含まれます。Windows Mobile では Windows 2000 / XP などと違い、ユーザーや ACL といった考え方がないため、事実上端末のユーザがすべてローカル管理者となるので、できればこの端末をロックダウン (利用遮断) したいところです。

端 末上のデータを守るには、SQL CE データベースの暗号化とアプリケーションへのログイン追加を検討してください。万が一、端末を紛失したり盗まれた場合のことを考えてください。誰かがアプ リケーションに攻撃を掛けた場合に備えて、ログイン失敗回数が一定以上を超えたらアプリケーションのデータを削除する、またはログインを可能にする時間を 長くすることができます。アプリケーションのデータをストレージ カードに常駐させている場合は、それらのカードは容易に端末から取り外し可能であり、また王位に読み取ることができるためデータ ファイルの暗号化を検討してください。

遠隔通信に対しては、SSL やできれば VPN などの暗号化伝送の使用を検討してください。または、送信前にカスタム暗号データも使用できます。大量のパケットが盗聴された場合、802.11b WiFi での共有鍵暗号方式は解読されることがあるので注意してください。

表 1 は、セキュリティ上のリスクを軽減できる技術をいくつかまとめたものです。

表 1 : セキュリティ分野とセキュリティ上のリスクを軽減するオプション

セキュリティ分野

オプション

データ保護

Microsoft Exchange Server

ファイルシステムフィルターを使用したカスタム ストレージ

CryptoAPI (「PKI インフラストラクチャ」項を参照)

Microsoft SQL Server™ CEセキュリティ

通信保護

PKI インフラストラクチャ

SSL による電子メール

仮想私設ネットワーキング

より安全な WiFi

SQL Server CE セキュリティ

端末のロックダウン
(利用遮断)

標準の境界セキュリティ

Pocket PC のカスタム パスワードによる境界セキュリティ

XML による端末管理

SQL Server CE セキュリティ

Smartphone アプリケーション セキュリティ

公開鍵インフラストラクチャ

PKI とは、セキュリティで保護された通信に役立つソフトウェアサービスと規格が集まったものです。プライバシーの暗号方式、ユーザの身元確認 / 認証と否認防止、データ ソースの整合性保護と証明などから構成されています。

ほ とんどのユーザが、暗号化にはデータの暗号化と解読に秘密鍵が必要と考えがちです。秘密鍵は漏洩してはいけないのですが、配信が必要なためここで問題が生 じます。公開鍵暗号化には、秘密鍵と公開鍵の 2 つの鍵を使用します。これによって自分の秘密鍵でデータを暗号化でき、配信可能な公開鍵で解読できます。この方法では、それらの公開鍵でしかデータを解読 できないので、暗号化されたデータのソースを判断できます。同様に、誰かの公開鍵でデータを暗号化した場合、正しい秘密鍵の所有者以外はそのデータを解読 できません。

PKI は公開鍵を、鍵の発行者、バージョン、有効期限などの付加情報を示すデジタル証明書として組み込みます。証明書もデジタル証明で署名されます。証明書の発 行者は証明書のコンテンツに基づいてハッシュを作成し、デジタル署名を構成する秘密鍵でこれを暗号化します。この証明書を受け取ったユーザは、署名を解読 してハッシュ値を復元できます。また、証明書からハッシュを生成して、両方のハッシュ値を比較します。両方のハッシュが同一であれば、その証明書が改ざん されていないことがわかります。

Microsoft は対称鍵 / 非対称鍵による暗号 / 解読などの PKI 規格を実装する CryptoAPI を用意しています。また、Microsoft Windows® CE .NET 4.2 には、表 2 に示すように設定で変えられる証明書ストアを用意しています。

表 2 : 設定で変えられる証明書ストア

ストア

説明

 

 

ROOT

このストアは、セキュリティで保護された Web セッション (HTTPS) であると信頼されたルート証明書を保管しています。

CA

このストアには、信頼された中間認証局があります。

MY

このストアは、セキュア ソケット レイヤー (SSL) チャネル、802.1x、VPN、電子メールの暗号化や署名、その他の方法により認証に使用する、ユーザ個人のクライアント証明書を保管します。これらは個人用証明書のため、秘密鍵も組み込まれています。

Smartphone にも、権限の実行を判断するストアがこの他にいくつか用意されています。詳細については、この記事の「Smartphone アプリケーション セキュリティ」の項を参照してください。

Pocket PC 2003 と Smartphone 2003 には、証明書を取り扱う設定アプレットが用意されています。図 1 と図 2 のように、端末上でルート証明書と個人用証明書を表示したり削除したりすることが可能です。

wmdeploy_img01.gif
図 1 : Pocket PC 証明書
ストア

wmdeploy_img02.gif
図 2 : Smartphone 証明書ストア

通 常、法人市場では、証明書は身元確認とセキュアなメッセージ通信を確保するために使用されています。多くのインフラストラクチャが、例えば Windows Server 2003 で実行されるような認証局 (CA) を用意しています。この CA サービスは、PKI 対応アプリケーションをサポートする証明書を発行します。Windows Server CA のセットアップ方法について詳しくは、『 Step-by-Step Guide to Setting up a Certificate Authority (英語) 』を参照してください。多くのブラウザがプレインストールされているルート証明書で出荷されるため、SSL 証明書については、第三者機関の CA から取得することをお勧めします。

Pocket PC と Smartphone の証明書アプレットには証明書のインストール機能はなく、証明書の一覧表示と削除を行えるだけです。

CA から証明書を登録するには、クライアントで現在のユーザを認証し、HTTP POST 経由で PCKS #10 証明書要求メッセージを作成してから HTTP GET を発行して証明書を入手する必要があります。この証明書が、CryptoAPI によって該当する証明書ストアに保管されます。「Pocket PC 2003 (SDK for Windows Mobile 2003-based Pocket PCs) (英語)」 でも 「Smartphone 2003 SDK (SDK for Windows Mobile 2003-based Smartphones) (英語)」 でも、SDK のインストール先ディレクトリ配下の Samples\Win32\Enroll ディレクトリに登録サンプルコードを用意しています。このサンプルはネイティブアプリケーションなので、まず 「Microsoft eMbedded Visual C++ 4.0 (SDK for Windows Mobile 2003-based Pocket PCs (英語)」 をインストールする必要があります。マネージアプリケーションを開発する場合には、まず 「Microsoft Visual Studio .NET 2003 (Microsoft Visual Studio Developer Center) (英語)」 をインストールしてください。

Pocket PC 2003 でも、ファイル エクスプローラで .cer 拡張子付きルート証明書ファイルをインストールできます。証明書を端末にコピーして、ファイル エクスプローラで開くだけです。

例えば、証明書をルート ストアにプログラムで追加する方法のコードについては 『 Windows モバイル 2003 Smartphone と Windows モバイル 2002 Smartphone にルート証明書を追加する方法 』を参照してください。

もともと、アプリケーションにはユーザ名とパスワードを組み合わせた認証ユーザ機能があります。PKI とこの Windows Mobile プラットフォームでは、ユーザを認証するためにこれ以外のオプションを用意しています。

•提示するもの : 証明書 (端末上のスマートカード、トークン)

•入力するもの : ユーザ名、パスワード、フレーズ

•身体的特質 : 生体測定セキュリティ (HP5550 での親指の指紋スキャナ)

•個人的特質 : 署名 (筆跡速度も測定できる Pocket PC スタイラスでキャプチャする)

多 元的な認証はこれら認証オプションのうち 2 つか 3 つを組み合わせて、不正なアクセスをさらに削減できます。例えば端末が盗まれた場合、アプリケーションの実行に必要な証明書が入っていたら、アプリケー ションの実行に PIN が必要でない限り、セキュリティが破られてしまします。

Cryptography API

Pocket PC と Smartphone には、ハッシュ、対称 / 非対称暗号方式、証明書サポートなどのセキュリティ規格を必要とするアプリケーション開発向けに CryptoAPI (CAPI) を用意しています。CAPI では図 3 に示すようにプロバイダモデルを採用しています。暗号化アルゴリズムはサービス プロバイダ (CSP) によって提供されています。

wmdeploy_img03.gif
図 3 : CryptoAPI プロバイダ モデル

Windows CE .NET 4.2 には、表 3 に示すようにスマート カード プロバイダの他に基本 RSA プロバイダと拡張 RSA プロバイダがあります。拡張 CSP は、より長い鍵とさらなるアルゴリズムを用意しています。Windows CE .NET 4.1 以降では、拡張 RSA プロバイダがディフォルトの CSP になります。

表 3 : Windows CE .NET 4.2 の基本アルゴリズムと拡張アルゴリズム

アルゴリズム

基本

拡張

RSA 鍵交換

512 bit

1024 bit

RSA 署名

512 bit

1024 bit

RC2 ブロック

40 bit

128 bit

RC4 ストリーム

40 bit

128 bit

RC5 ブロック

未対応

128 bit

DES

未対応

56 bit

トリプル DES (2 つの鍵)

未対応

112 bit

トリプル DES (3 つの鍵)

未対応

168 bit

そ れぞれの CSP が、対称または非対称いずれかの暗号化アルゴリズムを 1 つ提供します。CAPI には、アルゴリズムの処理と操作に一般的な方法を用意しています。暗号化鍵がセキュリティで保護されるよう、直接アクセスできない内部鍵データベースをそ れぞれの CSP が提供します。この鍵は、鍵データベース内の鍵コンテナに保管されます。この関係を図 4 に示します。

wmdeploy_img04.gif
図 4 : CSP データベースとコンテナの関係

セッション鍵は自動的には存続しません。鍵を保管するには、鍵 BLOB に出力する必要があります。この仕組みは、セキュリティで保護された鍵交換に使用されます。詳細については、MSDN の 『 Key BLOBs (英語) 』を参照してください。鍵が存続する必要のないよう、セッション鍵をパスワードから得ることもできます。

次に、端末上でデータの暗号化と解読を実行できる例を説明します。このサンプルでは、ユーザが入力したパスワードから対称鍵を生成します (図 5 参照)。RC2 ブロック アルゴリズムでデータを暗号化するのに使用しています。

wmdeploy_img05.gif
図 5 : ファイルの暗号化と解読サンプル

データを暗号化または解読する前に、CSP のハンドルを取得する必要があります。この場合はデフォルトの RSA プロバイダを入手する必要があります。

CryptAcquireContext (&hProv, NULL, NULL, PROV_RSA_FULL, 0);

次に、MD5 ハッシュ オブジェクトを作成します。これで、パスワードをハッシュすることができます。

CryptCreateHash (hProv, CALG_MD5, 0, 0, &hHash);
CryptHashData (hHash, (PBYTE)lpszPassword, _tcslen(lpszPassword), 0);

次に、RC2 セッション鍵をパスワード ハッシュから取得します。この鍵でデータの暗号化と解読が行えます。

CryptDeriveKey (hProv, CALG_RC2, hHash, 0, &hKey);
// encrypt data
CryptEncrypt (hKey, 0, bEOF, 0, pbBuffer, &dwCount, dwBufferLen);
// or decrypt data
CryptDecrypt (hKey, 0, bEOF, 0, pbBuffer, &dwCount);

図 6 と図 7 に、平文データと暗号化データを示します。

wmdeploy_img06.gif
図 6 : 平文データ

wmdeploy_img07.gif
図 7 : 暗号化データ

パ スワードで RC2 セッション鍵を取得するため、データを暗号化 / 解読する前にユーザにこのパスワードの入力が求められます。暗号化データを別のユーザに送信するには、両者が同一のパスワードを知っている必要がありま す。PKI をセキュリティで保護された鍵交換に使用すれば、パスワードを手動で別のユーザに教える必要がありません。詳細については、MSDN の 『 Exchanging Session Keys (英語) 』 を参照してください。

Exchange Server と SSL による電子メール

Windows Mobile 2003 端末は、追加アプリケーションなしで Exchange Server に接続でき、電子メール、連絡先、予定表の同期をサポートしています。Exchange Server 2003 は標準でこの機能を搭載しています (Server ActiveSync を有効にしてください)。

同期処理はセキュアな HTTPS 経由で動作しますが、HTTP もサポートしています。このため WiFi 対応端末の他、Smartphone や Pocket PC Phone Edition などの組み込み無線スタックを備えた端末であればデータサービスを利用して無線による同期が可能です。この他「有線対応のみ」の端末の場合は、ネットワー クカードを搭載していればサーバに接続し、または、USB 経由で PC に接続して PC のネットワーク接続を利用し同期を行うことができます。

Windows Mobile 2003 端末では、SSL セキュア チャネルを使用しないように端末を設定できます。ただしその場合は、暗号化されていないため傍受される危険性があります。

HTTPS 経由の接続の場合、Exchange をホストしている組織は、SSL 証明書の購入が必要になります。小規模な組織であれば、HTTP 経由で同期化を図ることもできますが、ユーザー名とパスワード (とデータ) がクリアテキストで送信されることになります。ファイアウォールで保護された社内での利用であれば、このセキュリティ水準でも許容範囲と言える場合もあり ます。ネットワーク内で傍受されるリスクのみを考慮してください。HTTP 経由で社外から同期を取る必要がある場合は、ファイアウォール経由で VPN の使用を検討してください。これによって、暗号化パケットの使用で社外ではよりセキュリティが向上しますが、社内ネットワーク内ではデータはオープンなま まです。HTTPS の方が、クライアントからサーバまでセキュリティで保護されたチャネルを実現できることを念頭に置いてください。

Windows Mobile 2003 端末にインストールされているルート証明書

•Entrust.net Secure Server

•Entrust.net CA (2048 bit)

•Equifax Secure Certificate Authority

•GlobalSign Root CA

•GTE Cybertrust ROOT

•GTE Cybertrust Solutions ROOT

•Secure Server Certifricate

•Thawte Server CA

•Thawte Premium Server CA

•Verisign Class 2 Public Primary CA

•Verisign Class 3 Public Primary CA

Pocket PC をサポートする RSA SecurID (英語) を使用するよう Exchange ActiveSync を設定すれば、より一層電子メール送信チャネルを保護できます。60 秒ごとに変わるランダム アクセス コードと PIN を組み合わせることで、2 つの要素を使った認証が実現します。この認証はソフトウェアに組み込まれており、RSA が提供する Pocket PC クライアント ソフトウェアを入手できます。新しいコードが 60 秒ごとに生成されるため攻撃時期が極端に限られ、より一層セキュリティが向上する方法です。

RSA SecurID ダウンロードのセットアップ方法と設定方法について詳しくは 『 Exchange Server 2003 Deployment Guide (英語) 』 を参照してください。

S/MIME を使用するとデジタル署名付きでメッセージを暗号化できるため、機密保持と身分証明が行いやすくなります。この処理はクライアント上で行うので、メール サーバ上では標準の MIME メッセージと同様に S/MIME を取り扱います。S/MIME メッセージを送信するユーザは、X.509 証明書 / 秘密鍵でメッセージに署名します。受信者は、送信者の公開鍵でメッセージを解読します。これは送信者が本人で、メッセージが改ざんされていないことの確認 にもなります。また逆に、共有鍵の暗号方式にも使用することができます。ユーザは共有鍵を作成して、添付ファイルを暗号化できます。受信者の公開鍵でメッ セージを暗号化して、この共有鍵を受信者に送信できます。このようにして受信者だけが秘密鍵でメッセージを解読できるため、共有鍵を発見できます。 S/MIME サポートは、今後 Windows Mobile にも装備する予定です。より一層セキュリティの高いメッセージ交換が可能になるはずです。

クライアントのログ出力

クライ アントとサーバ間のデータ同期には、HTTP 経由で AirSync プロトコルを使用します。本体は XML で GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS、CONNECT などの各種動詞を使用します。典型的な同期セッションでは、まずサーバのフォルダ階層の同期化を図り、転送すべき項目を見積もってからデータの完全な同期 を実行します。

相互接続問題がなければ、設定したシステムで同期が失敗することはまずありません。何か問題がないか診断するには、クライアントに詳細ログを設定してください。HTTP ヘッダや XML 本体など、AirSync 処理のすべてがログで出力されます。

Pocket PC 2003 でログをオンにするには、Microsoft ActiveSync® を起動してください。

1.    [ ツール ] → [ オプション ] を選択します。

2.    [ サーバー ] タブを選択します。

3.    [ サーバー ] ボタンを選択します。

4.    [ ルール ] タブを選択します。

5.    [ ログ出力 ] を [ 簡易 ] または [ 詳細 ] に変更します。

Smartphone 2002 でログをオンにするには、ActiveSync を起動してください。

1.    [メニュー] → [1 オプション] を選択します。

2.    [3 サーバー設定] を選択します。

3.    [4 接続] を選択します。

4.    [メニュー] → [1 ルール] を選択します。

5.    [ログ出力] を [簡易] または [詳細] に変更します。

wmdeploy_img08.gif
図 8 : ActiveSync ログ出力

同 期に影響するよくある状況には、端末の空きメモリ領域が足りない、サーバのメールボックスが一杯である、などがあります。また例えば、端末を古いバック アップイメージから復元し、続いてユーザのメールボックスをサーバに移動した場合などは、クライアントとサーバ間で使用する同期化鍵が一致しないことがあ ります。この場合、同期化する項目を選択解除すれば解決できます。このようにして端末上のデータを削除します。この項目を再び選択しなおして、同期化を実 行します。

仮想私設ネットワーキング

VPN を使用すると、公共のインターネットを独自のプライベートネットワークとして使用することで、ネットワーク インフラストラクチャを拡張できます。これは、ルーティング情報を付加して、VPN 宛データをパケットごとに暗号化することで実現します。インターネット利用に掛かる諸経費は専用線を引くよりもはるかに安価で、インターネットに接続でき ればどこにいても操作が可能です。

Windows Mobile 2003 には図 9 と図 10 に示すように、以前からサポートしていた Point-to-Point Tunneling Protocol (PPTP) に加え、レイヤ 2 トンネリング プロトコル (L2TP) / インターネット プロトコル セキュリティ (IPSec) の拡張 VPN サポートがあります。

wmdeploy_img09.gif
図 9 : IPSec/L2TP VPN 設定 - 画面 1

wmdeploy_img10.gif
図 10 : IPSec/L2TP VPN 設定 - 画面 2

IPSec/L2TP を使用するとクライアント証明書で認証が可能になり、ただのユーザ名 / パスワードの組み合わせよりもさらに強力なセキュリティが得られます。または、共有秘密鍵の使用も可能になります。参考までに端末に証明書を与える方法に ついては、「公開鍵インフラストラクチャ」の項を参照してください

より安全な WiFi

Wired Equivalent Privacy (WEP) の暗号化は脆弱で、ワイヤレスデータを読み取れるセキュリティ上の弱点が公表されています。また、共有秘密鍵をベースにしていますがこの鍵はもともと公表 すべきもののため、接続クライアントを限定するのが難しくなっています。小規模な無線 LAN であればネットワーク MAC アドレス上のクライアントをフィルタ処理できるものもありますが、これでは大企業内では拡張性がありません。有効な解決策は、802.1X 規格を実装することです。これは拡張可能認証プロトコル (EAP) を使用し、クライアント証明書を実装してよりセキュリティの高い通信を実現できるため、確実にクライアント端末の身元確認と暗号鍵交換を実行できます。こ れは、ユーザ / 端末ごとに証明書を発行する CA の他、クライアント証明書を認証するインターネット認証サービスを必要とします。これらの設定方法について詳しくは 『 Securing Wireless LANs - A Windows Server 2003 Certificate Services Solution : Build Guide (英語) 』 を参照してください。

Microsoft Pocket PC 2003 Second Edition には Wi-Fi Protected Access (WPA) もプラットフォームに用意し、セキュリティをより一層高めています。各パケットの整合性強化に加え、新型フレーム カウンタによるリプレイ攻撃に対する防御策が含まれています。802.1X 認証メカニズムを採用していますが、802.11b とは違って暗号鍵の使用を必須としています。ユニキャスト トラフィック (1 対 1 の転送) の場合は、Temporal Key Integrity Protocol (TKIP) を使用して、フレームごとに新しい鍵を提供します。マルチキャストの場合は、動的にアップデートできるグローバルな暗号鍵を使用します。アクセスポイント では WEP 規格と WPA 規格の両方をサポートできますが、グローバル鍵 802.11g クライアントをサポートするため固定にする必要があります。

標準の境界セキュリティ

境界セキュリティの目的は、遠隔攻撃や悪質な攻撃に対して防御策を与えることです。強化すべき分野は、主に次の 3 つがあります。

•端末に対する物理的アクセス

•端末管理

•デスクトップの ActiveSync による遠隔呼び出し

端末に対する物理的アクセス

物 理的アクセスをセキュリティで保護する第一の仕組みは、端末にパスワードを使用することです。電源投入時または設定時間が過ぎたらパスワードの入力を強要 します。正しいパスワードを入力するまで、端末にアクセスできないようにします。次項のカスタム パスワード プロバイダの実装を参照してください。

端 末に拡張スロットがある場合は、自動再生機能を提供するよう設定することができます。これを有効にすると、ウィルスなどの攻撃的アプリケーションを無意識 にインストールしてしまう恐れがあります。この機能を有効 / 無効にする方法については 「XML による端末管理」 の項のセキュリティ ポリシーを参照してください。

Pocket PC Phone Edition と Smartphone 端末にも、SIM カードと通信する無線スタックを用意しています。これらの端末は、SIM ロックをサポートしているので SIM パスワードの設定が可能です。無線スタックをオンにしていると、ユーザは SIM をロック解除して無線アクセスを取得しようと 3 回まで試みることができます。それ以降は、SIM カードがロックされ、ロック解除には SIM オペレータからの支援が求められます。

端末管理

Windows Mobile 2003 には、インターネット情報サービス (IIS) に類似したコンフィギュレーション メタベースが用意されています。これは、端末に影響を与える可能性のある各種操作を拒否または承認できるものです。IIS6.0 のように XML ドキュメントを直接修正して設定を変更する代わりに、ActiveSync の Remote API (RAPI) を利用し、OTA で介された XML メッセージで端末を設定できます。または、DMProcessConfigXML API 呼び出しで端末内のコードで直接設定できます ( 「XMLによる端末管理」 の項を参照してください)。

表 4 に、Windows Mobile 端末に利用できるポリシーを記載します。

表 4 : 端末管理ポリシー

ポリシー 説明

Smart phone

Pocket PC

AutoRun

このポリシー設定は、端末に挿入した時点で、SD や CF などの拡張カードに格納しているアプリケーションを自動再生できるかどうかを決定します。

あり

あり

Grant Manager

こ のポリシー設定は、Manager ロールのもつ管理者権限を、メタベースの設定を変更することなく、Manager ロール以外のセキュリティロールに与えます。特にこの Grant Manager ポリシーは、ロールマスクを Manager ロールにマッピングします。

Configuration Manager によって、このセキュリティ ポリシーが強制的に実行されます。

あり

あり

Grant User Authenticated

こ のセキュリティ ポリシー設定を使用すると、他のロールでも SECROLE_USER_AUTH ロールに扮することができます。特にこのセキュリティ ポリシーは、SECROLE_USER_AUTH ロールがアクセスできるメタベース設定ごとに割り当てているセキュリティ ロールを変更しなくても、特定のロールマスクを SECROLE_USER_AUTH ロールにマッピングすることを許可します。

あり

あり

Message Authentication

このポリシー設定は、ワイヤレス アプリケーション プロトコル (WAP) の PIN 署名メッセージの認証に、何回までのリトライを許容するか定義します。

あり

あり

OTA Provisioning

このポリシー設定は、メッセージに割り当てられているロールに基づいて、どの設定や変更メッセージを Configuration Host で受け入れるかを決定します。このポリシーによって、Push Router から着信する設定や変更メッセージが限定されます。

Configuration Host の詳細については 「Push Router からのデータ (Data from Push Router)」 を参照してください。

あり

あり

PrivilegedApps

一層 (すべての実行が特権モードになる) または二層 (署名付き証明書に応じて、権限付与または権限なしにできる。「Smartphone アプリケーション セキュリティ」参照) のセキュリティ モデルのうち、どちらを使用するか決定します。

あり

なし

RAPI

この RAPI ポリシーは、モバイル 端末での ActiveSync 操作を実行するのに、リモート API (RAPI) を使用している遠隔アプリケーションのアクセスを制限します。

あり

あり

Service Loading
ポリシー

SL メッセージを受け入れるかどうかを決定します。

あり

なし

Service Indication
ポリシー

SI メッセージを受け入れるかどうかを決定します。

あり

なし

TPS

このポリシー設定は、モバイル オペレータを、WAP 設定 / 変更に対して信頼されている設定 / 変更サーバ ロールに割り当てられるかどうかを決定します。

あり

あり

Trusted WAP

このセキュリティ ポリシー設定は、信頼するプロキシの作成、変更、削除に必要なアクセス許可レベルを指定します。

あり

あり

Unauthenticated Messages

Unauthenticated Messages ポリシー。このポリシー設定は、発信元に応じて Security Module (Push Router) 内の既定セキュリティ プロバイダが処理した WAP 署名以外のメッセージを受け入れるかどうか決定します。

あり

あり

Unsigned .cabs

このセキュリティ ポリシー設定は、署名なしの .cab ファイルを端末にインストールできるかどうかを決定します。

あり

なし

Unsigned Applications ポリシー

署名なしのアプリケーションを Smartphone で実行できるかどうかを決定します。

あり

なし

Unsigned Prompt ポリシー

Smartphone に署名なしのアプリケーションがインストールされたり実行された場合、ユーザに通知するかどうかを決定します。

あり

なし

WAP Signed Message

このポリシー設定は、発信元に応じて、また SECROLE_USER_AUTH セキュリティ ロールがあるかどうかに応じて、WAP 署名付きメッセージの処理方法を決定します。

あり

あり

WSP Push

このポリシー設定は、ルーティングされた WAP スタックからの Wireless Session Protocol (WSP) 通知を受け入れるかどうか決定します。

あり

あり

例えば autorun ポリシーを変更するには、XML ドキュメントの作成が必要です。

<!-- Sample XML to change autorun device policy  -->
<wap-provisioningdoc>
   <characteristic type="SecurityPolicy">
      <!--
      Policy ID 2
      Possible values
      1 - Applications are restricted
      0 - Applications can run
      -->
      <parm name="2" value="1" /> 
   </characteristic>
</wap-provisioningdoc>

この設定 XML を Windows Mobile 端末に送信する方法については 「XML 設定 / 変更 (XML Provisioning)」 の項を参照してください。

XML 設定のパラメータ詳細などの詳細については、Pocket PC 2003 SDK ヘルプの 「 Device Management Policies (英語) 」 を参照してください。

デスクトップの ActiveSync による遠隔呼び出し

Remote API (RAPI) は、デスクトップと端末間のリモートプロシジャーコール (RPC) を行います。ActiveSync は、この RAPI を頻繁に使用します。例えばパートナー関係を構築したり、デスクトップと端末間でファイルのコピーをやり取りしている間に、RAPI によって電子メール設定が構築されます。これが組織にとってはセキュリティ上リスクになりかねないため、RAPI を有効にするか無効にするか制限することができます。また起動パスワードの設定でも RAPI の呼び出しを防ぐことができます。

<!-- Sample XML to change RAPI device policy  -->
<wap-provisioningdoc>
   <characteristic type="SecurityPolicy">
      <!--
      Policy ID 4097
      Possible values
      0 - All RAPI calls are disabled
      1 - All RAPI calls are allowed
      2 - RAPI calls in restricted mode
      -->
      <parm name="4097" value="0" /> 
   </characteristic>
</wap-provisioningdoc>

RAPI には制限モードを設定することができます。これにより SECROLE_USER_AUTH (User Authenticated) ロールに応じて呼び出しを制限できます。これで WAP 署名以外の WAP プッシュ メッセージと署名なし .cab ファイルを除いて、大抵の状況を網羅することができます。ロールの詳細については、Pocket PC 2003 SDK のヘルプにある 「Security Roles on Pocket PC (英語) 」 を参照してください。

Pocket PC のカスタム パスワードによる境界セキュリティ

パ スワードセキュリティは、端末へのアクセスを制限するのに有効な仕組みです。既定の起動アプレットを使用して、固定の 4 桁または文字列によるパスワードを指定できます。この他にもタイムアウト設定があり、起動パスワードのダイアログの表示タイミングを調節できます。図 11、図 12、図 13は、既定のパスワード設定を示しています。

wmdeploy_img11.gif
図 11 : 既定のパスワード設定 - 画面 1

wmdeploy_img12.gif
図 12 : 既定のパスワード設定 - 画面 2

wmdeploy_img13.gif
図 13 : 既定のパスワード設定 - 画面 3

ま たカスタム セキュリティの必要性があれば、カスタム パスワード アプレットをプラグインすることもできます。例えば指紋ハードウェアが装備されている場合、指紋データのハッシュをキーに使用することができます。また、 筆跡速度を記憶した署名をキャプチャすることも可能なため、より一層偽造しにくくなります。また、いつ端末が起動したかのログを取ることも可能です。この カスタム機能を導入するには、互換性のある内部 StartUI コンポーネントが端末に必要です。OEM 製品でもこれらをカスタマイズできますが、これらの方法との互換性が保たれない恐れがあるため、ハードウェアを再度テストしてください。

カスタム起動パスワードの作成には、図 14 に示すようにコントロール パネル アプレットの作成と、パスワード データの設定 / 認証という 2 段階があります。

wmdeploy_img14.gif
図 14 : 起動パスワードの構造

パスワード コントロール パネルはシンプルな Win32 DLL ですが、表 5 に示すように 2 つのメソッドをエクスポートします。アプレットの場合、Pocket PC の [ 設定 ] 内 (コントロール パネル) に表示するにはファイルの拡張子を .cpl に変更する必要があります。

表 5 : パスワード DLL の出力

メソッド

説明

CPlApplet

このメソッドにより、Pocket PC の [設定] (コントロール パネル) から基本的なメッセージ処理を行えます。例えば、CPL ライブラリによりアイコンとキャプションを [設定] ダイアログから設定し、クリック イベントを処理してカスタム パスワード機能を表示できます。

PromptForPasswd

このレジストリを変更して、パスワード呼び出しをカスタム パスワード CPL ライブラリにリダイレクトします。パスワードが設定されている状態でユーザが端末を起動すると、このメソッドが呼び出されます。

CPlApplet 機能には [ 設定 ] (コントロール パネル) からメッセージを受信する Windows プロシージャ ハンドラがあります。

LONG CALLBACK CPlApplet(HWND hwnd, UINT uMsg, LONG lParam1, LONG 
 lParam2) {
   switch(uMsg) 
   {
      case CPL_INIT:
         return TRUE;
      case CPL_GETCOUNT:
         return 1L;
      case CPL_IDNAME:
         // Registry subkey -- 
HKEY_LOCAL_MACHINE\ControlPanel\...
            lstrcpy((LPTSTR)lParam2, TEXT("password")); 
            return 0;
      case CPL_NEWINQUIRE:
        {
         LPNEWCPLINFO lpNewCPlInfo = (LPNEWCPLINFO)lParam2;
         if ( lParam1 != 0 ) // Applet index -- we only have 
one.
            return 0;
         // Set up our sole applet
            lpNewCPlInfo->dwSize = (DWORD)sizeof(NEWCPLINFO);
            lpNewCPlInfo->dwFlags = 0;
            lpNewCPlInfo->hIcon = (HICON)LoadImage(   g_hInstance, 
                                    MAKEINTRESOURCE(ICON_SIMPLEPASSWORD), 
                                    IMAGE_ICON, 32, 32, 0 );
 
            lstrcpy( lpNewCPlInfo->szName, g_pszAppletCaption );
            lstrcpy( lpNewCPlInfo->szInfo, TEXT("A simple password 
protection replacement.") );
            return 0;
        }
 
        case CPL_DBLCLK:
        {         
         if ( lParam1 != 0 ) // Applet index -- we only 
 have one.
            return FALSE;
         // Show custom password dialog
         ShowSecurityDialog((HWND)0, FALSE);
         return TRUE;
        }      
      case CPL_EXIT:
      case CPL_SELECT:
      case CPL_STOP:
      default:
         break;
   }
   return 0;
}

コントロール パネル アプレットからの情報を要求するには、CPL_NEWINQUIRE メッセージを使用します。ここではアイコンとテキストを設定するのに使用します。ユーザがコントロール パネル アプレットを選択すると、CPL_DBLCLK メッセージが送信されます。次に、カスタム パスワード プロバイダ (ドライバ) に表示する必要が生じます。このメッセージ ハンドラの実装は、いずれのカスタム コントロール パネル アプレットの作成にも使用します。

さらに、PromptForPasswd メソッドを実装する必要があります。このメソッドは、端末を起動してから設定で変更できる一定時間が経過した後に呼び出されます。続いてこのメソッドはカ スタム パスワード入力を表示し、このパスワードを OS に戻します。パスワードが本物であることが証明されたら、ユーザは端末にアクセスできます。それ以外はメソッドが再び呼び出され、ダイアログを再度表示し ます。第 2 のパラメータ fTightSecurity は未使用で、常に真にしておきます。

LPTSTR PromptForPasswd(HWND hwndParent, BOOL fTightSecurity) {
   TCHAR*   pszPassword;
   // Prompt the user and handle all the custom security stuff
   ShowSecurityDialog(hwndParent, TRUE);   
   pszPassword = (TCHAR*)LocalAlloc(
0,
sizeof(TCHAR)*lstrlen(g_pszDesktopPassword) + 1 );
   lstrcpy(pszPassword, g_pszDesktopPassword);
 
   // Return the password entered by the user
   // This is verified by the OS
    return pszPassword;
}

パスワード アプレットにはカスタム ユーザ インターフェイスが必要です。サンプルのコードは、単純に 3 色から選択するパスワードです。この例では図 15 と図 16 に示すように、メッセージの処理にダイアログを使用する標準的なダイアログを使用しています。

wmdeploy_img15.gif
図 15 : 簡易カスタム パスワード ア
プレット - 画面 1

wmdeploy_img16.gif
図 16 : 簡易カスタム パスワード アプレット - 画面 2

次に、システムからパスワードの確認、設定、有効化、無効化、クリアを実行できるようにする必要があります。これには、表 6 に示すように以下のパスワード API を使用します

表 6 : パスワード API

メソッド

説明

SetPassword

このメソッドは、パスワードの設定に旧 (もしくは空の) パスワードと新パスワードを要求します。

SetPasswordActive

現 在のパスワードをアクティブにします。さらに、起動してカスタム パスワード CPL PromptForPasswd メソッドを呼び出した時にこの SetPasswordActive が設定されていれば、StartUI コンポーネントを設定してチェックすることもできます。この設定については 「レジストリの設定 (Registry Settings)」 を参照してください。

GetPasswordActive

パスワードがアクティブの場合、真を返します。

PromptForPasswd

パ スワードがアクティブで起動時に OS がパスワードを確認するよう設定されている場合、カスタム パスワード CPL に出力されたこのメソッドが呼び出されます。パスワードは、OS が検証できる文字列として返す必要があります。この文字列は LocalAlloc で割り当てる必要があり、OS によって開放されます。
これは OS から呼び出されているパスワード プロバイダ (ドライバ) のため、厳密にはパスワード API と異なります。

これらのパスワード メソッドをコードに使用する前に、それらを明確に関連付ける必要があります。

extern "C" {
BOOL SetPassword( LPWSTR lpszOldPassword, LPWSTR lpszNewPassword );
BOOL SetPasswordActive( BOOL bActive, LPWSTR lpszPassword );
BOOL GetPasswordActive();
}

最後に、カスタム パスワード アプレットを導入するには、CPL ファイルを \Windows ディレクトリにコピーします。次に、デスクトップの ActiveSync による接続時や端末の起動時などにパスワードが正しく適用されるよう、表 7 に示すようにいくつかのレジストリ設定を変更します。

表 7 : パスワード レジストリの設定

キー

[HKLM\ControlPanel\Password]

値

"Redirect"=STRING:"\windows\SimplePassword.cpl"

説明

パスワード チェックをカスタム パスワード CPL にリダイレクトするのに必要です。Pocket PC 2002 の場合は、プロバイダ (ドライバ) に password.cpl という名前が付けられます。

キー

[HKLM\Security\Policies\Shell] (Pocket PC 2003 の場合)

[HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Shell] (Pocket PC 2002 の場合)

値

"ActivePeriod"=DWORD: <分>

説明

パスワード プロバイダ (ドライバ) が表示されるまでの時間 (分単位)

キー

[HKCU\ControlPanel\Owner]

値

"PowrPass"=REG_BINARY:(0x00 または 0x01)

説明

0x01 に設定した場合は、起動パスワードが有効で OS から PromptForPasswd が呼び出されます。それ以外は、パスワード プロバイダ (ドライバ) が起動時に呼び出されません。

カスタム パスワードのプロバイダ (ドライバ) をエミュレータにインストールすると、エミュレータ ファイル システムが最新の CPL ファイルを取得して [ 設定 ] ダイアログが最新の情報に更新されます。端末の場合、インストール後に新しい CPL が表示されるよう、端末を再起動するのが最良の方法です。Pocket PC のユーザ インタフェース パスワード リダイレクトである Let Me In のサンプルには、代わりのパスワード プロバイダ (ドライバ) 例として、ポイント一覧で点字を入力するものもあります。この方法はこの一覧をレジストリ内に格納して、固定のパスワード文字列を用意しています。ポイン ト一覧を文字列に変換し、図 17 のようにこれによりパスワードを取得するので、より安全です。

wmdeploy_img17.gif
図 17 : Let Me In 起動パスワードのサンプル

Let Me In サンプルには、eMbedded Visual C++ 3.0 と Pocket PC 2002 SDK が必要です。また、このサンプルは Pocket PC 2003 と互換性があります。詳細およびダウンロードについては 「 Let Me In : Pocket PC User Interface Password Redirect Sample 」 ページを参照してください。

Smartphone アプリケーション セキュリティ

Smartphone には、Pocket PC と比較して格段上のセキュリティを用意しています。特定のアプリケーションに対し、インストールも実行も行えないようにします。これには、証明書でアプリ ケーションや .cab ファイルに署名しておき、これをアプリケーション ローダで検証します。さらに、端末で権限付与と権限なしという 2 種類の実行モードを使用できます。権限付与の実行ではすべての API にアクセスできる一方、権限なしでは SIM 機能など一部の API にアクセスできません。通常、大多数のアプリケーションが権限なしモードで正常に動作します。権限付与の実行を必要とする場合は、端末のモバイル オペレータと連携してハードウェアをテストしてください。このセキュリティを図 18 に示します。

wmdeploy_img18.gif
図 18 : Smartphone 実行の概要

ア プリケーション ローダは非常に柔軟に設定でき、デフォルト設定はオペレータごとに異なります。例えば、AT&T の MPx200 がオープンで署名なしアプリケーションの実行を許可しているのに対し、Smartphone を初めて搭載した Orange 社の SPV は Orange 社が署名して信頼したアプリケーションのみ実行を許可します。

このアプリケーション ローダを使用すると、バイナリ ファイルのハッシュ値を失効リストと照合します。失効リストに存在すれば、証明書を失効リストと照合します。失効リストに存在すれば、実行できません。証 明書に署名があり、その実行が権限モードであれば、権限ストアと照合します。または、権限なしストアで照合できた場合は、その実行は権限なしとなります。 どちらのストアでも証明書チェーンを検証できなかった場合は、そのアプリケーションは署名なしとして取り扱われます。

例えばすべての署名なしアプリケーションの実行を許可するには、次の XML ドキュメントでセキュリティ ポリシーを変更できます。

<!-- Sample XML to change unsigned applications device policy  -->
<wap-provisioningdoc>
   <characteristic type="SecurityPolicy">
      <!--
      Policy ID 4102
      Possible values
      1 - Unsigned applications are allowed to run on the device
      0 - Unsigned applications are not allowed to run on 
the device
      -->
      <parm name="4102" value="1" /> 
   </characteristic>
</wap-provisioningdoc>

セキュリティ ポリシーは一部の端末では読み取り専用の場合があるため、開発およびテストには、オペレータにセキュリティ ポリシーのロックを解除してもらってください。

オ ペレータごとに異なる権限と権限なしルート証明書を付与する場合は、ソフトウェア開発会社がオペレータごとおよびアプリケーションごとに署名する必要があ ります。証明されたアプリケーションの普及に役立つよう、Microsoft では Mobile2Market (M2M) ルート証明書を Smartphone 2003 プラットフォームにインストールしました。M2M 証明に合格したアプリケーションには、Verisign (英語)社外サイトへのリンクや (英語)社外サイトへのリンクなどの認証局を通じて署名してください。このアプリケーションは CAB インストール ファイルにまとめられるので、ここでさらに署名が必要です。 (英語) には Smartphone 2003 のルート証明書のみではなくそれ以上のものを用意しています。ユーザ インタフェース ガイドラインの他、モバイル アプリケーション カタログ ロゴの証明済みアプリケーションなどを用意しています。

Smartphone セキュリティの詳細については、MSDN の 『 A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers (英語) 』 をお読みください。

XML による端末管理

Smartphone 2002 に必要なものの 1 つに、XML 設定 / 変更、すなわち端末設定を行う API があります。設定変更は、端末からアプリケーションを使用してローカルに処理できる他、モバイル オペレータによって無線 (OTA) 経由で遠隔からでも処理できます。このインフラストラクチャは、Pocket PC 2003 と Smartphone 2003 プラットフォームの両方に組み込まれています。XML 設定 / 変更は様々なことを柔軟に実現でき、DMProcessConfigXML という簡易メソッドを 1 つだけ実装しています。コンフィギュレーション サービス プロバイダ (CSP) の設定リストは膨大で、ブラウザのお気に入り管理、接続マネージャ (GPRS、VPN、プロキシ エントリ)、電子メール、アプリケーション管理からレジストリ処理まで多岐にわたります。Smartphone と Pocket PC に共通の CSP でも違いがあるものもありますし、どちらかにしかない CSP もあります。

多数の端末を導入している企業の場合、電子メール アカウントのセットアップとユーザに対する WiFi、GPRS、VPN 接続設定を行えるアプリケーションを作成できるよう、CSP に関連性を与えるべきです。表 8 は、Smartphone と Pocket PC 両方の CSP を示しています。Smartphone または Pocket PC Phone Edition 搭載端末を販売するオペレータのうち多くは、ユーザ情報を少し入力してもらい、電子メール、ブラウザのお気に入り、GPRS 設定を CSP で自動的に設定するようなウィザード アプリケーションをバンドル (セット売り) しています。

表 8 : コンフィギュレーション サービス プロバイダ (CSP)

CSP (ドライバ)

説明

Smart phone

Pocket PC

BOOTSTRAP

端末の Trusted Provisioning Server (TSP) を設定します。

あり

あり

BrowserFavorite

端末のお気に入りリストから URL を追加 / 削除します。

あり

あり

CertificateStore

セキュリティ証明書とロール マスクを端末の証明書ストアに追加します。

あり

あり

Clock

端末の日時を設定します。

あり

なし

CM_GPRSEntries

端末のジェネラル パケット ラジオ サービス (GPRS) のエントリを設定します。

あり

あり

CM_Mappings

URL マッピング テーブルを設定します。

あり

あり

CM_ NetEntries

端末の追加のネットワーク エントリを設定します。例えば、Desktop Passthrough (DTPT) ネットワーク エントリなどがあります。

あり

あり

CM_Networks

端末のネットワーク接続を設定します。

あり

あり

CM_Planner

Connection Manager の優先接続を設定します

あり

あり

CM_PPPEntries

端末のポイント ツー ポイント プロトコル (PPP) のエントリを設定します。

あり

あり

CM_ProxyEntries

端末のプロキシ接続を設定します。

あり

あり

CM_VPNEntries

端末の仮想私設網 (VPN) のエントリを設定します。

あり

あり

CM_WiFiEntries

端末のワイヤレス ネットワーク (WiFi) のエントリを設定します。

なし

あり

EMAIL2

Pocket PC 2003 と Smartphone 2003 端末のインターネット プロトコル電子メールサービスを設定します。

あり

あり

FileOperation

端末のファイルとディレクトリを管理します。例えば、ショートカット作成などを管理します。

あり

なし

Home

端末の Smartphone の Home 画面を設定します。

あり

なし

Install

setup.dll のロードとアンロードなど、アプリケーションのインストールとアンインストールを処理します。

あり

あり

LoaderRevocation

アプリケーションが起動しないよう、失効リスト中の証明書またはバイナリ ハッシュを追加、削除、照会するのに使用します。

あり

なし

Locale

端末の地域設定を行います。

あり

なし

Metabase

メタベースからエントリの追加、変更、削除を行うのに使用します。

あり

あり

NAPDEF

ワイヤレス アプリケーション プロトコル (WAP) ネットワークのアクセス ポイント定義 (NAPDEF) とその設定を追加、変更、削除します。

あり

あり

Obex

Bluetooth / 赤外線を使って、着信する赤外線ビームと Bluetooth ビームを有効 / 無効にする Obex サーバを設定します。

あり

なし

PXLOGICAL

ワイヤレス アプリケーション プロトコル (WAP) の論理プロキシと物理プロキシを追加、削除、変更します。

あり

あり

Registry

端末のレジストリを設定します。

あり

あり

SecurityPolicy

モバイル 端末のセキュリティ ポリシー設定を設定します。「標準の境界セキュリティ」 から 「端末管理ポリシー」 を参照してください。

あり

あり

Sounds

端末の各種イベントに関連付けられている音を設定します。

あり

なし

Sync

端末の同期設定を設定します。

あり

あり

TAPI

端末の GSM 設定を設定します。例えば、着信転送設定などを設定します。

あり

なし

UnInstall

端末からアプリケーションを削除します。

あり

なし

CSP を使用すると電子メール アカウントがいかに簡単に設定できるかを説明します。必要なのは、XML 設定 / 変更ドキュメントを EMAIL2 CSP に作成し、DMProcessConfigXML を呼び出して XML で応答側 XML の出力バッファにアクション フラグとポインタを受け渡すだけです。アクション フラグは、XML 設定 / 変更ドキュメントで XML (CFGFLAG_PROCESS) を処理するか、または XML を参照してパラメータ要素 (CFGFLAG_METADATA) のメタデータのうち何かを返すかを決定します。例えばセキュリティ ポリシーの読み出しなどを返します。

HRESULT      hr;               //result
TCHAR      *XmlIn = NULL;         //xml provisioning doc
TCHAR      *OutputBuf = NULL;   //ouput buffer
 
VERIFY(XmlIn = new TCHAR[600]);
 
//create the provisioning doc. in this case to add a new POP3 account
//look up "email2 csp" in sdk help index for full syntax
_tcscpy(XmlIn, TEXT("<wap-provisioningdoc>"));
_tcscat(XmlIn, TEXT("<characteristic type=\"EMAIL2\">"));
//each account on the device needs a unique GUID
_tcscat(XmlIn, TEXT("<characteristic type=\"
{4FE84006-9E8A-4158-864D-A2E1E98C3787}\">"));
_tcscat(XmlIn, TEXT("<parm name=\"SERVICENAME\" value=\"MyPOP2\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"SERVICETYPE\" value=\"POP3\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"INSERVER\"    
value=\"pop3.myserver.com\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"OUTSERVER\"   
value=\"smtp.myserver.com\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"AUTHNAME\"    value=\"alias\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"AUTHSECRET\"  
value=\"password\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"DOMAIN\"      
value=\"mydomain\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"REPLYADDR\"   
value=\"emailAddress@server.com\"/>"));
_tcscat(XmlIn, TEXT("</characteristic>"));
_tcscat(XmlIn, TEXT("</characteristic>"));
_tcscat(XmlIn, TEXT("</wap-provisioningdoc>"));
 
//process the provisioning doc and create the e-mail account
hr = DMProcessConfigXML(XmlIn, CFGFLAG_PROCESS, &OutputBuf);

すべての CSP は、WAP プッシュ ゲートウェイまたは RAPI を利用して SMS 経由で無線 (OTA) で送信することもできます。OTA メッセージは有効な署名かどうか確認され、セキュリティ ポリシーによっては破棄されることがあります。「 Effect of Device Management Policies on the OTA Process (英語) 」 を参照してください。

CSP に加えて、Windows Mobile には XML で設定できる端末管理ポリシーも用意しています。詳細については、前述の 「標準の境界セキュリティ」 の項を参照してください。

RAPIConfig.exe

コ マンドラインツールの RAPIConfig.exe を使用して、RAPI 上の XML 構成を端末に送信することもできます。このツールは、Pocket PC 2003 および Smartphone 2003 SDK の \Tools ディレクトリにあります。

たとえば、同一の e-mail 構成を XML ファイルに保存できます。

<!-- email.xml -->
<wap-provisioningdoc>
   <characteristic type="EMAIL2">
   <!-- each account on the device needs a unique GUID -->
      <characteristic type="
{4FE84006-9E8A-4158-864D-A2E1E98C3787}">
         <parm name="SERVICENAME" value="MyPOP2"/>
         <parm name="SERVICETYPE" value="POP3"/>
         <parm name="INSERVER" value="pop3.myserver.com"/>
         <parm name="OUTSERVER" value="smtp.myserver.com"/>
         <parm name="AUTHNAME" value="alias"/>
         <parm name="AUTHSECRET" value="password"/>
         <parm name="DOMAIN" value="mydomain"/>
         <parm name="REPLYADDR" 
value="emailAddress@server.com"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

これら CSP のうちの 1 つは、端末セキュリティポリシーであり、XMLでポリシーを変更できるかを制御します。

その後、端末を ActiveSync に接続すると、以下のパラメータを使用して、この XML がデスクトップから端末に提供されます。

RapiConfig.exe /P /M email.xml

RAPIConfig.exe パラメータ

RapiConfig の形式は RAPICONFIG [/P] [/M] XmlDataFile です。表 9 に RAPIConfig.exe パラメータを示します。

表 9 : RAPIConfig.exe パラメータ

パラメータ

概要

/P

RapiConfig に xml 構成を処理し、端末を変更するように伝えます。

/M

RapiConfig に呼び出しのメタデータを返すように伝えます。このパラメータは RapiConfigOut.xml ファイルに保存されます。

XmlDataFile

これは xml 構成のドキュメントを含む xml ファイルです。

/M パラメータを使用してメタデータを返す場合、RapiConfig によって XmlDataFile の内容が処理され、その後、XmlDataFile の設定に合わせたメタデータが抽出されます。たとえば、上記の email.xml ドキュメントは、EMAIL2/{4FE84006-9E8A-4158-864D-A2E1E98C3787} という特性タイプのメタデータを返します。

<wap-provisioningdoc>
   <characteristic type="EMAIL2">
      <characteristic type="
{4FE84006-9E8A-4158-864D-A2E1E98C3787}">
         <parm name="SERVICENAME" value="MyPOP2"/>
         <parm name="SERVICETYPE" value="POP3"/>
         <parm name="INSERVER" value="pop3.myserver.com"/>
         <parm name="OUTSERVER" value="smtp.myserver.com"/>
         <parm name="AUTHNAME" value="alias"/>
         <parm name="AUTHSECRET" value="password"/>
         <parm name="DOMAIN" value="mydomain"/>
         <parm name="REPLYADDR" 
value="emailAddress@server.com"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

これは、指定の CSP または端末管理ポリシーに対して現在の設定を返す際に便利です。たとえば、これにより、EMAIL2/{4FE84006-9E8A-4158-864D-A2E1E98C3787} という特性タイプと同じメタデータが返されます。

c<wap-provisioningdoc>
   <characteristic type="EMAIL2">      
      <characteristic type="
{4FE84006-9E8A-4158-864D-A2E1E98C3787}">
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

File System Filter を使用したカスタムな記憶域

一 般的に、モバイル端末は小型軽量、低消費電力であるため、固定ディスク記憶域はあまり適しません。代わりに、RAM と ROM をベースにしたファイルシステムが組み込まれています。Pocket PC や Smartphone の多くには、CF（Compact Flash）スロットや SD（Secure Digital）スロットによって拡張できる記憶域が用意されています。これらの記憶域は、FAT ファイルシステムを使用してフォーマットされます。

Windows CE .NET 4.0 には、カスタムファイルシステムフィルタ（FSF）をプラグインする機能が導入されました。これらのフィルタは、ファイルシステム（メモリファイル記憶域 またはストレージカード）とファイルシステムを使用するアプリケーションの間にあります。CreateFile や ReadFile などの FSF 標準ファイルシステム関数を使用して、処理をインターセプトしたり、追加の処理を割り当てたりすることができます。FSF の使用例にはウイルススキャン、記憶域の暗号化、および CF カードや SD カードの圧縮があり、正しいFSFインストールした端末でのみカードを読み書きすることができるようになります。

Storage Manager によりファイルストアにアクセスできるので、ハードディスク、CD-ROM、CF/SD などのさまざまな記憶装置を併用できるようになります。Storage Manager では、記憶装置がオンライン（PnP）になると通知されます。一方、File System Driver（FSD） Manager は、インストール済みのすべての FSD および FSF とともに使用して、ファイルシステムにパーティションドライバをロードできます。CF カードまたは SD カードを挿入すると、Storage Manager に通知され、対応する FSD のロードが試行されます。この間、図 19 で示すように、ロードする必要がある適切な FSF がないかどうかを確認するためこのレジストリが検索されます。

wmdeploy_img19.gif
図 19 : Storage Manager のアーキテクチャ

FSF DLL が検索されると、StorageManager は、基本となるファイルシステムの情報を含む FSF のFSD_HookVolume を呼び出します。FSF と FSF をチェーンできるため、基本となるファイルシステムが実際の FSD とは別の FSF になる場合があるので注意してください。

本ドキュメントのサンプルコードには、簡単な XOR ハッシュ処理によって書き込まれたすべてのデータをエンコードし、CF カードや SD カードから読み出したすべてのデータをデコードする FSF の例が含まれています。

FSF をロードすると、tFILTER_HookVolume メソッドが呼び出されます。ハッシュキーの値が設定されていることに注意してください。この値は、ファイルシステムのデータを読み書きする際に使用されます。

BYTE *hashkey = NULL;
PVOLUME FILTER_HookVolume(HDSK hdsk, FILTERHOOK *pHook) {
   VolumeState *pState;
   pState = new VolumeState;
   pState->hDsk = hdsk;
   memcpy( &pState->FilterHook, pHook, sizeof(FILTERHOOK));
 
   // Set hashkey for encryption/decryption
   GetHashKey();
 
   return (PVOLUME)pState;
}

ReadFile メソッドをインターセプトする例を以下に示します。ハッシュキーを使用してハッシュ値を元のデータに戻すための一時バッファでデータを読み込む方法を確認 してください。このデータは、出力バッファ、またその後呼び出しているアプリケーションに読み込まれます。

BOOL FILTER_ReadFile(PFILE pfh, 
LPVOID buffer, 
DWORD nBytesToRead, 
LPDWORD lpNumBytesRead,
LPOVERLAPPED lpOverlapped) 
{
   BOOL fSuccess = FALSE;
   HandleState *pHandle = (HandleState *)pfh;
 
   try {
      // Work with the buffer
      DWORD off =0;
 
      // Find the offset into the file. 
      off = pHandle->pHook->pSetFilePointer(pHandle->h,
      0,
      NULL,
      FILE_CURRENT);
      if (off != -1) {
         BYTE * unhashBuff = new BYTE[nBytesToRead];
 
         // Read the bytes into a temporary buffer.
         fSuccess = pHandle->pHook->pReadFile( 
                        pHandle->h,
                        unhashBuff,
                        nBytesToRead,
                        lpNumBytesRead,
                        lpOverlapped);
 
         // unhash data
         if (fSuccess) {
            div_t startpoint = div(off,hashkeysize);
            // iterate the buffer copying XOR with 
the hashkey
            for (long x = 0, y = startpoint.rem; x 
< *lpNumBytesRead; x++, y = (y<(hashkeysize-1)?y+1:0)) {      
               ((BYTE *)buffer)[x] = unhashBuff[x] 
 ^ hashkey[y];
            }
         } 
         else {
            // unable to read file
         }
         delete [] unhashBuff;
         unhashBuff = NULL;
      }
   }
 
   catch (...) {
      // failed somewhere
      fSuccess = false;
   }
   if (!fSuccess)   {
      fSuccess = pHandle->pHook->pReadFile( 
                     pHandle->h,
                     buffer,
                     nBytesToRead,
                     lpNumBytesRead,
                     lpOverlapped);
   }
return fSuccess;
}

FSF プロジェクトは、標準の SDK に含まれないヘッダーファイルを参照します。このプロジェクトをコンパイルするには、Windows CE.NET 4.2 Platform Builder をインストールし、C:\WINCE420\PUBLIC\COMMON\OAK\INC にある OEM Adaptation Kit ヘッダーを明示的に参照する必要があります。図 20 では、OEM 付属キットのインクルードファイルの追加を示します。

Evaluation Kit<--/a--> (英語) をダウンロードする場所などの詳細は、Windows CE .NET Product Overview (英語) を参照してください。

wmdeploy_img20.gif
図 20 : OEM 付属キットのインクルードファイルの追加

DLL が作成されたら、その DLL を端末と作成された以下のレジストリキーの \Windows ディレクトリに配置する必要があります。FSD Manager は、これらのキーを検索して FSF をロードします。

HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\Filters\<FSF の名前> キーの下に、表 10 に示す次の値を作成します。

表 10 : 作成する値

名前

タイプ

値

Dll

文字列

MyFSF.dll

Order

DWORD

0

ファイルシステムの複数の FSF をチェーンできます。チェーンした FSF は、Order 値の順序で実行されます。

Smartphone 2003 の場合、特権モードで実行していないと、HKEY_LOCAL_MACHINE\System\StorageManager\FATFS の下に任意のキーを作成できないため、FSF を簡単に実行できません。詳細は 「Smartphone アプリケーション　セキュリティ」 の項を参照してください。

FSF をオフにするには、図 21 の MyFSF の例のようにレジストリキーを削除するか、または Dll 文字列の値を無効なファイル名に変更します。端末をソフトリセットすると、FSF はメモリには残りません。

wmdeploy_img21.gif
図 21 : FSF のレジストリ設定

詳細は、Windows CE .NET 4.2 SDK ヘルプの File System Filters (英語) を参照してください。

FSF を使用すると、SD/CF カードのすべてのデータをシームレスに読み書きできるようになります。FSF がインストールされていない場合、図 22 と 23 で示すように、ファイル操作はできますが、アプリケーションで結果のデータを確認できません。

wmdeploy_img22.gif
図 22 : FSF をインストールした場合のファイル表示

wmdeploy_img23.gif
図 23 : FSF をインストールしていない場合のファイル表示

こ の例では、基本的な XOR 手法を使用して CF カードや SD カードのデータをロックしています。より安全性の高いソリューションとして、セッションキー ( 「CryptoAPI」の項を参照) や非対称暗号を使用してください。こうした例では、公開鍵を使用して書き込みと暗号化を行い、対応する秘密鍵を持つ端末でしかデータを読み取りまたは解読 できません。非対称暗号は処理プロセッサに高い負荷が掛かるので、今日のファイルシステムにはあまり適さない可能性があります。しかしながらモバイル PKI アプリケーションの需要があれば、シリコンベンダがモバイル端末用の PKI ハードウェアアクセラレータを製造することもないとは言えません。

SQL Server CE セキュリティ

SQL Server CE は、ANSI SQL の豊富な機能とSQL Server との各種接続オプションを提供する、Pocket PC 用の小型軽量データベースです。SQL Server CE のセキュリティを確保する上で、主に次の2 点を考慮する必要があります。

•

端末のデータベース。誰かがデータベースファイルを入手したらどうなるのか？

•

Pocket PC とリモートデータベースサーバ間の通信ユーザは認証されているか、チャネルは安全か？

ローカルデータベースのセキュリティ

ロー カルデータベースファイル (通常、SDF の拡張子が付く) は、ファイルレベルの暗号化を使用して作成することができ、アクセスするにはパスワードが必要です。現在のリリース (バージョン 2.0) では、ローカルデータベースへの単独接続のみをサポートします。ユーザの概念がないので、パスワードのみを使用してデータベースへのアクセスを制限しま す。パスワードは接続文字列で指定され、データベースを作成するときに割り当てる必要があります。

この項で紹介したソースはすべて C# を処理できるので Visual Studio .NET. で使用できます。

protected string connCE = @"Data Source=\mydata.sdf;Password=Hell0!";

後続のデータベース呼び出しは、正しいパスワードを指定した接続文字列を使用する必要があります。

SqlCeConnection conn = new SqlCeConnection(connCE);
conn.Open();
// Execute commands against connection
// ...
conn.Close();
conn.Dispose();

正しいパスワードを使用しないでデータベースを開こうとすると、図 24 で示すように SqlCeException の例外がスローされます。

wmdeploy_img24.gif
図 24 : ローカルファイルレベルのデータベースセキュリティ

パ スワードを指定してもデータベースを暗号化するわけではありません。データベースが開かれないようにするだけです。データベースを暗号化するには、データ ベースを作成したときに接続文字列を変更して暗号化の指定を含めます。その後、データベースは、RSA 128 ビットのファイルレベルの暗号を使用して暗号化されます。

protected string connCE = @"Data Source=\mydata.sdf;Password=Hell0!; 
encrypt database=TRUE";
SqlCeEngine engine = new SqlCeEngine(connCE);
engine.CreateDatabase();
engine.Dispose();

チャネルのセキュリティ

多くのアプリケーションには、リモート SQL サーバまたは外部データソースを使用した SQL Server CE のデータ通信が必要です。図 25 で示すように主に 4 つのルートがあります。表 11 では、各ルートを説明します。

wmdeploy_img25.gif
図 25 : SQL Server CE 接続オプション

表 11 : SQL Server CE のルートと概要

ルート

概要

SQL Server クライアントデータプロバイダ
(CE 端末の SqlClient プロバイダ)

このプロバイダは、SQL Server のインスタンスを直接実行する場合に便利です。永続的な接続を必要とします。

SqlClient プロバイダは SQL Server CE エンジンではなく、TDS (Tabular Data Stream) を使用してリモートの SQL Server インスタンスと交信します。通常、端末の TDS パケットは、TCP/IP パケットでカプセル化されます。

Web サービス

このルートは SQL Server に直接接続せず、ビジネスとデータのアクセスクラスなどのカスタムな機能を使用できます。HTTP を使用します。

マージレプリケーション

クライアントとサーバの両方の SQL Server CE エージェントを使用してデータを複数クライアントで更新できます。HTTP を使用します。

RDA
(リモートデータアクセス)

クライアントが SQL 文から結果セットを取り出すことができ、変更は自動的に追跡され、サーバに送信されます。HTTP を使用します。

Microsoft は、デスクトップやサーバの環境で広く使用される、閉環境向けに設計された TDS プロトコルを独自に実装しています。

他 の接続オプションは HTTP で動作します。Web サービスを使用してデータを転送する場合、安全なカスタムチャネルを実装することもできます。たとえば、SOAP ヘッダーを使用して SOAP 本文を暗号化することもできます。ただし、この方法は作業量が多いので (独自に WS-Security クライアントを記述しない限り) 標準となる可能性は少ないでしょう。現時点で推奨している方法は、SSL (Secure Sockets Layer) を使用して HTTP チャネルの安全性を確保する方法です。この方法はまた Merge モデルと RDA モデルにも適用できます。

チャネルセキュリティを設定する詳細は、MSDN の 「 Security Models and Scenarios for SQL Server 2000 Windows CE Edition 2.0 (英語) 」 または 「Configuring Security for Connectivity (英語) 」 を参照してください。

次の SQL Server CE のリリースには、1 つのデータベースに同時に複数の接続を行ったり、やデスクトップ版 SQL Server ツールとの統合などの優れた機能が完全に装備されます。

最後に

本 論文では、Pocket PC と Smartphone を安全に展開するのに役立つさまざまな手法を見てきました。それらの手法には、Exchange Server、PKI、802.1X WiFi などのインフラストラクチャが含まれるものや、Smartphone アプリケーションのセキュリティや XML 提供などのプラットフォーム機能と、カスタムなパワーオンパスワード（POP）、FSF（File System Filter）、SQL Server CE などの開発者手法とを組み合わせたものがあります。

脅威モデリング

すべてのアプリケーションとその 展開に完全なセキュリティオプションが必要なわけではなく、必要となるオプションは多くの要因により異なります。たとえば、端末をどのように展開します か？端末を外部に展開する場合は、端末の紛失が大きな問題となります。端末と他のシステムは内部で交信しますか、それとも外部で交信しますか？内部のネッ トワークのインターフェイスは、ネットワークを覗き見される可能性は低く、ネットワークのトラフィックや発信元を特定しやすくなります。

要 件定義から展開やサポートにいたるまで、セキュリティをアプリケーションの機能として割り当てるようにすると良いでしょう。脅威モデリングは、繰り返しの 段階的アプローチを使用して、脅威を発見、記録していきます。このモデリングは、アプリケーションやモバイル端末のデータなど、所有する資産を判断するこ とによって実現されます。その後、内部 / 外部のインターフェイスをどこで追跡し、どの範囲をどのレベルまで信頼するかという構造図を作成します。こうした情報を使用して、アプリケーションへのエ ントリポイント、信頼できる範囲やデータフローなど、アプリケーションセキュリティの機能を分析できます。こうした作業は、アプリケーションだけでなく、 ホスト (端末) とネットワークの脅威に対するリスクの特定に役立ちます。最後に、確認されたすべての脅威に対し、リスク評価を実行する必要があります。以下の方法で評価 を開始します。

Risk = Probablility * Impact

脅威モデリングは、アプリケーションが外部に出たときに何が起こるのかを包括的に分析するのに役立ちます。プロジェクトライフサイクル全般でこのプロセスを繰り返すことにより、アタックされるリスクを軽減できます。

詳細は、Patterns & Practices サイトの 「 Threat Modeling (英語) 」 を参照するか、または参考図書 「 Threat Modeling (Frank Swiderski and Window Snyder) (英語) 」 を参照してください。

これからのセキュリティ

Microsoft は、Windows Mobile を含むすべてのプラットフォームのセキュリティに投資しています。PKI は、Windows Server 2000 以降の製品の中核部分であり、Windows Mobile 2003 を使用すると、クライアントの利点をより生かすことができ、モバイルアプリケーションにも PKI を導入することができます。Microsoft .NET Compact Framework の開発チームは、よりマネージアプリケーションの開発に向け、セキュリティ機能の向上と今後のリリースの暗号化サポートを目指しています。