なぜ、いま shinten なのか？
漏れるのは「保管されたもの」
何年分もの注文記録、古い問い合わせの控え、使わなくなったプラグインが残したテーブル、バックアップ。漏洩のほとんどは通信の盗聴ではなく、保管されたデータの持ち出しです。暗号化したまま保管すれば、持ち出されるのは暗号文です。
小さな店ほど、守る負担が重い
ECサイトのプラグイン、外注の倉庫、SaaS のアカウント。住所が通る場所が増えるほど、守るべき場所も増えます。暗号化したまま通せば、守る場所は「復号する端末」だけになります。
鍵は、仕事をする人の手元に
鍵の保管庫も、鍵を預かるサービスも要りません。配送担当のパソコン、回答担当のスマホ。秘密鍵はそこに置き、サイトには公開鍵だけを載せます。復号の作業は、その人の AIエージェントに任せることもできます。
3分でわかる仕組み
ネットショップで、お客さまが商品を注文する場面を例にします。
お客さまがフォームに入力する
送信ボタンを押した瞬間、ブラウザが氏名、住所、電話番号を配送担当の公開鍵で暗号化します。郵便番号だけは、送料の計算のために暗号化せずに送ります。お客さまの操作はいつも通りで、登録もアプリも要りません。
サイトは暗号文を保管するだけ
サイトのサーバーとデータベースが受け取るのは、郵便番号と暗号文です。注文管理、バックアップ、外部連携のどこを通っても、中身は読めません。サーバー側に新しく入れるものはなく、届いたものをそのまま保存します。
配送担当の端末で復号する
送り状を印刷する担当者の端末にだけ秘密鍵があります。shinten-ship がそこで復号し、ヤマト B2 クラウドやゆうパックプリント R の取込ファイルを作ります。印刷が終われば取込ファイルを消し、住所はまた暗号文の中だけになります。
サイトが乗っ取られても公開鍵の差し替えに気付ける
フォームが使う公開鍵の一覧は、サイトが配っています。サイトを乗っ取った人は、この一覧に自分の公開鍵を足したり、一つを入れ替えたりして、以後の入力を自分でも復号できるようにしようとします。shinten はサイトを信じる代わりに、これが必ず表に出るようにしています。
どの鍵で暗号化したかを記録する
暗号文には、実際に暗号化に使った公開鍵の指紋(拇印)が、改ざんできない形で記録されます。鍵の名前は真似できても、指紋は真似できません。
承認した鍵以外は復号しない
配送担当は、自分が承認した公開鍵の一覧を持ちます。ほかの鍵でも暗号化された注文や、承認した鍵が欠けた注文が1件でもあれば、shinten-ship は送り状を1枚も作らずに止まります。一部のお客さまにだけ偽の鍵を配られていても、その注文で気付けます。
サイトの外から見張る
shinten watch が、サイトが配る公開鍵の一覧を定期的に確かめ、承認した鍵と違えば知らせます。注文が来る前に気付けます。
入力の瞬間に改ざんしたページを配る攻撃は、鍵と関係なく入力を読めるため、これでは防げません。防ぐには、入力欄をサイトが管理しない場所(別のドメインの iframe)から出す必要があります。
サイトに何が残り、何が残らないか
持たないもの
- 氏名、住所、電話番号(配送の型)
- 相談内容、返信先、氏名(問い合わせの型)
- 秘密鍵(サイトには置かない)
持つもの
- 郵便番号(送料や配送区分のため)、問い合わせの種別(振り分けのため)
- 暗号文(JWE 形式)。復号できるのは宛先の秘密鍵だけ
- 宛先の公開鍵の一覧(JSON 1枚)
データベースが丸ごと流出しても、出てくるのは郵便番号と暗号文だけです。
通信やディスクの暗号化との違い
| 一般的なサイト(HTTPS とディスクの暗号化) | shinten | |
|---|---|---|
| 守る場面 | 送信中と、ディスクが抜かれたとき | 保管中ずっと。サーバーのどこにあっても |
| サーバーが中身を読めるか | 読める(動いている間は復号済み) | 読めない |
| DB のダンプやバックアップの持ち出し | 守れない | 守れる(暗号文のまま) |
| 復号する場所 | サーバー | 秘密鍵を持つ担当者の端末だけ |
| サイトが乗っ取られたとき | 保管中のデータも読まれる | 保管済みの暗号文は読めない。公開鍵の差し替えは最初の注文で検知 |
| 導入に必要なもの | 証明書とサーバーの設定 | フォームに属性2つと公開鍵の公開。サーバー側の変更なし |
| 費用の構造 | 保守と監査 | ソフトは無料(Apache-2.0)。組み込みは自前か支援を依頼 |
導入に必要なもの
役割ごとに、持つものと動かすものを分けて示します。サーバー側に新しく動かすものはありません。
サイトの運営者(ネットショップ、問い合わせ窓口)
- フォームに属性を2つ足す(型と、公開鍵一覧の場所)。スクリプトを1本読み込む
- 受け取った暗号文を、暗号化しない項目(郵便番号など)と一緒にそのまま保存する。暗号文は、暗号化したときと同じ郵便番号と組でないと復号できない
- 公開鍵の一覧(JSON 1枚)をサイトに置く。担当者や控えの鍵が増えたら行を足す
復号する担当者(配送担当、回答担当)
- 自分の端末で鍵を作り、公開鍵だけをサイトの運営者に渡す。秘密鍵のファイルは本人だけが読める設定で作られる
- 承認した公開鍵の一覧を手元に持ち、復号のたびに照合する。サイトが配る一覧も shinten watch で定期的に確かめる
- 配送なら shinten-ship で、注文一覧から配送会社の取込ファイルを作り、印刷後に消す。問い合わせなら shinten のコマンドか AIエージェントで復号する
- 控えの鍵を必ず用意する。秘密鍵を失うと、その鍵だけで暗号化された内容は誰にも復号できない
お客さま
- いつも通りフォームに入力して送るだけ。登録もアプリも要らない
- JavaScript の動くブラウザが必要
- お客さまの端末に残るものはない
現在のバージョンでできること
できること
- 配送(shipping)と問い合わせ(inquiry)の型。ブラウザ用スクリプト、ライブラリ、コマンドライン、MCP サーバー
- shinten-ship: ヤマト B2 クラウド(基本レイアウト)とゆうパックプリント R の取込ファイルの作成、印刷後の消去と記録
- 複数の宛先(担当者と控えの鍵)への暗号化。郵便番号など暗号化しない項目の差し替えの検知
- 公開鍵の差し替えの検知(承認した鍵との照合、shinten watch)
これから
- Shopify、WooCommerce、Salesforce など既存システムへの部品
- 入力欄をサイトの外から出す仕組み(iframe)
- 配送会社の追加(佐川急便など)
- deedlog による「いつ復号して、いつ消したか」と公開鍵の変更履歴の証跡
技術者向け
- インストール
- サイト側は
<script src="…/shinten.browser.js">1本、またはnpm install shinten。配送担当はnpm install -g shinten-ship。Node.js 20 以上。 - 暗号文の形式
- JWE(JSON シリアライズ)。P-256 の JWK へ ECDH-ES+A256KW、宛先ごとに1受信者。暗号化しない項目は AAD として暗号文に結び付き、差し替えると復号できない。
- 使った鍵の記録
- 保護ヘッダーに、暗号化した公開鍵の RFC 7638 拇印を記録する。
open(sealed, key, { recipients })は承認した鍵と完全に一致しない暗号文をRecipientErrorで拒否する。 - 型(プロファイル)
- shipping は postalCode だけ平文で、name と address が必須。inquiry は category だけ平文で、message が必須。型が知らない項目は必ず暗号化する。平文と同じ名前の項目が暗号文の中にあれば、復号を拒否する。
- 復号する側
- コマンドラインは
shinten keygen -o / seal / open -r / inspect / watch。MCP サーバーはSHINTEN_KEYの秘密鍵で復号し、SHINTEN_RECIPIENTSの鍵と照合し、平文をどこにも書かない。 - 守れないもの
- 入力の瞬間に改ざんされたページ(侵害済みのサーバー)は、暗号化する前に読める。SRI と CSP で窓を狭め、防ぐには入力欄をサイトの外から出す。秘密鍵を失うと、その鍵だけで暗号化した内容は復号できない。
- ライセンス
- Apache-2.0。shinten、shinten-ship(GitHub)と npm。
- 関連
- 顧客情報を持たない共通ポイント kangoh。同じ「持たない」設計の姉妹プロジェクト。
導入のご相談
ネットショップや問い合わせ窓口への組み込み、配送業務や倉庫との連携、鍵の運用設計についてご相談ください。ソフトウェアは無料で使えます。費用がかかるのは設計と組み込みの支援です。
送信された内容は、お問い合わせへの対応にのみ使用します。このサイトには保存されません。取り扱いは プライバシーポリシーをご覧ください。