Virtual Phone Numbers for SMS Verification

Features

SMS認証の流れ: 概要

大まかに言えば、SMS認証は以下のステップに従います:

1. ユーザーが認証を必要とするアクションを開始する
2. サーバーがワンタイムパスワード（OTP）を生成する
3. サーバーがOTPをSMSゲートウェイ経由で送信する
4. SMSゲートウェイがメッセージをキャリアネットワーク経由でルーティングする
5. メッセージがユーザーの携帯電話に届く
6. ユーザーがOTPをアプリケーションに戻力する
7. サーバーがOTPを検証する
8. アクションが承認または拒否される

各ステップについて詳しく見ていきましょう。

ステップ1: 認証のトリガー

SMS認証は、本人確認を必要とする特定のユーザーアクションによってトリガーされます:

• アカウント作成: サインアップ時に電話番号を確認する
• 新しいデバイスからのログイン: 認識されていないデバイスまたは場所からアクセスする場合に本人確認を行う
• パスワードのリセット: パスワードの変更を許可する前にアカウントの所有者を確認する
• トランザクションの承認: 高額または異常な金融トランザクションを検証する
• プロファイルの変更: 機密性の高いアカウント設定を変更する前に本人確認を行う

アプリケーションのバックエンドロジックが、検証が必要かどうかを判断します。これは通常、IPアドレス、デバイスのフィンガープリント、地理的な場所、行動パターンなどの要素を評価するリスク評価アルゴリズムに基づいています。

リスクベースのトリガー

現代のプラットフォームは、すべてのアクションを検証するわけではありません。代わりに、適応型リスクスコアリングを使用します:

• 低リスク （認識されたデバイス、通常の場所）: 検証は必要ありません
• 中リスク （新しいデバイス、同じ国）: メール認証で十分な場合があります
• 高リスク （新しいデバイス、別の国、VPNが検出された）: SMS認証がトリガーされます
• 重大リスク （金融取引、パスワードの変更）: SMS認証が必須

このリスクベースのアプローチは、セキュリティとユーザーエクスペリエンスのバランスをとり、不要な摩擦を減らしつつ保護を維持します。

ステップ2: OTPの生成

認証がトリガーされると、サーバーはワンタイムパスワードを生成します。これが暗号化の役割です。

OTPの生成方法

OTPを生成する方法は主に2つあります:

HOTP（ハッシュベースのワンタイムパスワード）

HOTPは、RFC 4226で定義されており、カウンター値に基づいてパスワードを生成します:

1. サーバーに秘密鍵が保存されます
2. カウンター値が維持されます（OTP要求ごとにインクリメントされます）
3. HMAC-SHA1アルゴリズムが秘密鍵とカウンターを結合します
4. 結果が切り捨てられて、人間が読めるコード（通常4〜8桁）が生成されます

式: HOTP(K, C) = Truncate(HMAC-SHA1(K, C))

ここで、Kは秘密鍵、Cはカウンター値です。

TOTP（時間ベースのワンタイムパスワード）

TOTPは、RFC 6238で定義されており、SMS認証に最もよく使用されます。カウンターの代わりに時間ベースの値を使用します:

1. 現在のUnixタイムスタンプが時間ステップ（通常30秒）で割られます
2. この時間由来の値は、HOTPアルゴリズムのカウンターを置き換えます
3. 結果として得られるコードは、現在の時間ステップでのみ有効です

式: TOTP(K) = HOTP(K, floor(T/X))

ここで、Tは現在の時刻、Xは時間ステップ（例：30秒）です。

乱数生成

多くの実装では、HOTP/TOTPを完全にスキップし、代わりに暗号的に安全な乱数ジェネレーター（CSPRNG）を使用してコードを生成します:

1. サーバーは安全なエントロピーのソースを使用して乱数を生成します
2. その番号は4〜8桁のコードとしてフォーマットされます
3. コードはサーバーのデータベースに有効期限のタイムスタンプとともに保存されます
4. ユーザーがコードを送信すると、保存された値と比較されます

このアプローチは実装が簡単で、多くのウェブアプリケーションで使用されています。

OTPの特性

生成方法に関係なく、適切に設計されたOTPには以下の特性があります:

• ユニーク: 各コードは以前のものと異なる必要があります
• 予測不可能: 以前のコードを知っていても、将来のコードを推測するのに役立たないようにする必要があります
• 時間制限: コードは短時間（通常60〜300秒）で期限切れになります
• 1回限り: 各コードは1回しか使用できません
• 十分なエントロピー: ブルートフォース推測を防ぐために十分な長さ（6桁= 1,000,000通りの組み合わせ）

ステップ3: SMSゲートウェイとの通信

OTPを生成した後、サーバーはそれをSMS経由で配信する必要があります。これがSMSゲートウェイの役割です。

SMSゲートウェイとは

SMSゲートウェイは、インターネットとモバイルキャリアネットワークの間のブリッジとして機能するサービスです。アプリケーションはAPIを介してメッセージを受け取り、キャリアインフラストラクチャを介してSMSメッセージとして配信します。

サーバーとゲートウェイの通信方法

アプリケーションサーバーは、SMSゲートウェイのAPIにリクエストを送信します。典型的なAPIリクエストは次のようになります:

POST /api/v1/messages
{
  "to": "+1234567890",
  "from": "VERIFY",
  "body": "Your verification code is: 847293. Valid for 5 minutes.",
  "callback_url": "https://app.example.com/sms/status"
}

ゲートウェイは、メッセージIDとステータスで応答します:

{
  "message_id": "msg_abc123",
  "status": "queued",
  "price": 0.0075
}

主要なSMSゲートウェイプロバイダー

いくつかの企業が大規模なSMSゲートウェイサービスを提供しています:

• Twilio: 最も人気があり、何億ものメッセージを処理しています
• Vonage (Nexmo): 強力な国際的なカバレッジ
• Sinch: メッセージングと音声に重点を置いています
• MessageBird: ヨーロッパを拠点とするプロバイダー
• AWS SNS: AmazonのSMSサービス
• Plivo: 費用対効果の高い代替手段

これらのプロバイダーは、世界中の何百ものモバイルキャリアとの関係を維持し、地球上のほぼすべての電話番号へのメッセージ配信を可能にしています。

ステップ4: メッセージのルーティング

SMSゲートウェイがメッセージを受け取ると、適切なキャリアネットワークにルーティングする必要があります。これはプロセスの中で最も複雑な部分の1つです。

SS7ネットワーク

シグナリングシステムNo. 7（SS7）は、ほとんどの世界の電話ネットワークを制御するプロトコルスイートです。SMSが送信されると、SS7ネットワークをいくつかのコンポーネント経由で通過します:

SMSC（ショートメッセージサービスセンター）: SMSメッセージを保存および転送する中央ハブ。すべてのキャリアは1つ以上のSMSCを運営しています。

HLR（ホームロケーション登録）: 電話番号がどのネットワークに属し、加入者が現在どこにいるかを知るデータベース。

MSC（モバイルスイッチングセンター）: 加入者の現在の場所を提供する基地局にメッセージをルーティングします。

ルーティングプロセス

1. SMSゲートウェイがメッセージをアグリゲーターまたは直接キャリア接続に送信します
2. アグリゲーターがHLRに照会して宛先キャリアを決定します
3. メッセージが宛先キャリアのSMSCにルーティングされます
4. SMSCが自社のHLRに照会して加入者の現在の場所を見つけます
5. SMSCがメッセージを適切なMSCに転送します
6. MSCがメッセージを加入者にサービスを提供する基地局に配信します
7. 基地局がメッセージを無線周波数で電話に送信します

国際ルーティング

国際メッセージの場合、プロセスはより複雑です。メッセージは、宛先に到達する前に複数のキャリア、アグリゲーター、および国際ゲートウェイを通過する場合があります。各ホップは潜在的な遅延と障害ポイントを導入します。

これは、SMSの配信時間が、宛先の国とキャリアによって1秒未満から数分まで大きく異なる原因です。

仮想番号ルーティング

メッセージが仮想電話番号（VerifySMS.appなどのプロバイダーによって提供される）に送信されると、ルーティングはわずかに異なるパスをたどります:

1. メッセージは通常どおりキャリアネットワークに入ります
2. 仮想番号プロバイダーがキャリアまたはアグリゲーターレベルでメッセージを傍受します
3. 物理的なデバイスに配信する代わりに、メッセージはプロバイダーのサーバーにルーティングされます
4. プロバイダーがメッセージをウェブダッシュボードに表示するか、APIを介して配信します

この傍受により、仮想電話番号が可能になります - メッセージが物理的なSIMカードに届く必要はありません。

ステップ5: メッセージの配信

ルーティングされると、メッセージはエンドデバイス (または仮想番号プラットフォーム) に配信される必要があります。

物理的な電話への配信

従来の物理的な電話への配信:

1. 基地局は電話をページングし、受信メッセージを知らせる
2. 電話はページングを承認する
3. メッセージは専用のシグナリングチャネルを介して送信される
4. 電話はメッセージを保存し、ユーザーに通知する
5. 電話は配信確認をSMSCに送信する

仮想番号の配信

仮想番号の場合:

1. メッセージは仮想番号プロバイダーのサーバーに到着する
2. プロバイダーのシステムはメッセージを処理する (送信者、コンテンツ、タイムスタンプを抽出する)
3. メッセージはプロバイダーのデータベースに保存される
4. ユーザーはダッシュボード、API webhook、またはプッシュ通知を介して通知される
5. メッセージはユーザーが読むために表示される

VerifySMS.app のようなサービスは、このプロセスを速度のために最適化し、通常、受信から 1-5 秒以内にメッセージをユーザーに配信します。

ステップ 6: ユーザーがコードを入力する

ユーザーは、電話または仮想番号ダッシュボードから検証コードを読んで、アプリケーションに入力します。このステップは単純に見えますが、興味深い技術的な考慮事項があります:

オートフィルとオートリード

現代のモバイルオペレーティングシステムは、受信した検証コードを自動的に検出できます:

• Android: SMS Retriever API を使用すると、アプリは SMS 権限を要求せずに検証コードを自動的に読み取ることができます
• iOS: 検証コードのオートフィルは、メッセージ内の OTP を検出し、キーボードで提案します

これらの機能は、特定のメッセージ書式設定に依存します。メッセージには、認識可能なパターンでコードを含める必要があります。一部の実装では、セキュリティを強化するためにドメイン結合ハッシュを含めることがあります。

Web OTP API

Web アプリケーションの場合、Web OTP API を使用すると、ブラウザは受信した SMS メッセージから検証コードを自動的に抽出できます (ユーザーの許可が必要です)。これにより、検証プロセスがさらに合理化されます。

ステップ 7: サーバーの検証

ユーザーがコードを送信すると、サーバーはそれを検証します:

検証チェック

1. コードの一致: 送信されたコードは生成された OTP と一致しますか?
2. 有効期限: コードは期限切れですか? (通常、60-300 秒)
3. 使用状況: このコードはすでに使用されていますか? (リプレイ攻撃を防止)
4. 試行回数制限: ユーザーは最大試行回数を超えましたか? (ブルートフォースを防止)
5. 電話番号の一致: コードは正しい電話番号に対応していますか?

レート制限

サーバーは、悪用を防止するためにレート制限を実装します:

• 電話番号あたりの検証要求の最大数/時間
• セッションあたりのコード送信試行の最大数
• 要求間のクールダウン期間
• 分散型攻撃を防止するための IP ベースのレート制限

失敗した場合の処理

検証に失敗した場合:

• ユーザーは再試行を求められます (残りの試行回数が表示されます)
• 試行回数が多すぎると、セッションは一時的にロックされます
• 電話番号は一時的に新しいコードを受信できなくなる場合があります
• 極端な場合、アカウントはレビューのためにフラグが立てられる場合があります

ステップ 8: 認可

検証に成功した場合:

1. サーバーは電話番号を検証済みとしてマークします
2. ユーザーのセッションは検証済みステータスに更新されます
3. 元のアクション (アカウント作成、ログイン、トランザクション) が認可されます
4. ユーザーに確認が送信されます
5. セキュリティ監視のための監査ログが更新されます

SMS 検証のセキュリティ上の強みと弱み

強み

普遍性: SMS は、基本的なフィーチャーフォンから最新のスマートフォンまで、あらゆる電話で動作します。アプリのインストールは不要です。

シンプルさ: ユーザーは SMS を理解しています。プロセスは直感的で、技術的な知識がほとんど必要ありません。

所持要因: SMS 検証は、ユーザーが特定の電話番号を所持していること (またはアクセスできること) を確認し、パスワード以外の 2 番目の要因を追加します。

グローバルリーチ: SMS は、世界中のほぼすべての電話番号に到達できます。

弱み

SS7 の脆弱性: 1970 年代に設計された SS7 プロトコルには、攻撃者が SMS メッセージを傍受できるようにする既知のセキュリティ脆弱性があります。高度な攻撃者は、これらを悪用して検証コードをキャプチャできます。

SIM スワッピング: 攻撃者は、被害者の電話番号を新しい SIM カードに転送するようにモバイルキャリアを説得できます。これにより、被害者の SMS メッセージを受信でき、検証コードも含まれます。

マルウェア: 感染したデバイス上のモバイルマルウェアは、SMS メッセージを傍受し、ユーザーが見る前に検証コードをキャプチャできます。

ソーシャルエンジニアリング: 攻撃者は、フィッシングまたはソーシャルエンジニアリングを使用して、ユーザーを騙して検証コードを明らかにすることがあります。

配信の信頼性: SMS 配信は保証されていません。メッセージは遅延、損失、またはキャリアによってブロックされる可能性があり、ユーザーエクスペリエンスが低下します。

暗号化なし: 標準の SMS メッセージは、エンドツーエンドで暗号化されていません。配信チェーンのさまざまなポイントで傍受される可能性があります。

SMS 検証の現代的な代替手段

SMS のセキュリティ上の弱点により、いくつかの代替手段が登場しています:

TOTP 認証アプリ

Google Authenticator や Authy のようなアプリは、デバイス上で時間ベースのコードをローカルに生成します。これらのコードはネットワークを経由しないため、傍受されません。

プッシュ通知

サービスは、検証済みのデバイスにプッシュ通知を送信し、ユーザーがタップで要求を承認または拒否できるようにします。コードを入力するよりもユーザーに優しいです。

FIDO2/WebAuthn

ハードウェアセキュリティキーと生体認証は、最も強力な検証を提供します。これらはフィッシングに強く、電話番号にも依存しません。

電子メールベースの検証

電子メール検証は、SMS (SS7、SIM スワッピング) の特定の脆弱性を回避しますが、異なるトレードオフを伴います。

なぜ SMS 検証が存続するのか

SMS 検証は、その普遍的なリーチのために存続します。誰もがスマートフォンアプリを持っているわけではありません。誰もがセキュリティキーを持っているわけではありません。しかし、ほぼすべての人が SMS を受信できる電話を持っています。このため、SMS 検証は、今後も最も広く使用される 2 番目の要因であり続けるでしょう。

仮想番号がどのように絵に収まるか

VerifySMS.app のようなサービスからの仮想電話番号は、キャリアルーティングレベルで SMS 検証システムと相互作用します。これらは、SMS メッセージを受信できる正当な電話番号として機能しますが、メッセージは物理的なデバイスではなく Web ダッシュボードに配信されます。

送信アプリケーションと SMS ゲートウェイの観点から、仮想番号は従来のキャリア番号と区別がつきません (プロバイダーが高品質のキャリアグレードの番号を使用している場合)。検証コードは、生成、送信、ルーティング、配信と、まったく同じインフラストラクチャを経由して行われます。

これが、仮想番号が SMS 検証に機能する理由です。これらは、SIM カードではなくサーバーをエンドポイントとして使用する点を除いて、実際の電話番号だからです。

よくある質問

SMS 認証にはどれくらいの時間がかかりますか？

コードのリクエストから配信まで、通常は 5 ～ 30 秒かかります。ただし、キャリアの混雑、国際的なルーティング、またはゲートウェイ処理により、遅延が発生する場合があります。

一部の SMS コードが届くまでに時間がかかるのはなぜですか？

遅延は通常、キャリアの混雑、複数のキャリアを経由した国際的なルーティング、送信サービスによるレート制限、一時的なネットワーク問題によって発生します。

SMS 認証コードを傍受することはできますか？

はい、SS7 の悪用、SIM スワッピング、またはデバイスのマルウェアによって傍受される可能性があります。そのため、セキュリティ専門家は、重要なアカウントにはアプリベースの 2FA を推奨しています。

SMS コードは通常、6 桁なのはなぜですか？

6 桁の数字には 1,000,000 通りの組み合わせがあり、コードの有効期間が短い場合にブルートフォース攻撃を防ぐのに十分です。レート制限と組み合わせると、適切なセキュリティが提供されます。

仮想番号は実際の電話と同じように SMS を受信しますか？

仮想番号は、同じキャリアインフラストラクチャを介して SMS を受信します。違いは、メッセージが物理的なデバイスではなくサーバーに配信されることです。送信者から見れば、違いはありません。

結論

SMS 認証は、暗号化、電気通信、およびユーザーエクスペリエンスデザインの興味深い交差点です。既知のセキュリティ制限はありますが、最も普遍的にアクセス可能な 2 要素認証の形式であり続けています。

SMS 認証が技術的にどのように機能するかを理解することは、あなた自身のセキュリティについて十分な情報に基づいた決定を下すのに役立ちます。個人の電話番号を公開せずに SMS 認証が必要な状況では、VerifySMS.app のような仮想番号サービスは、同じ技術フレームワーク内で動作する信頼性が高く、プライバシーを保護する代替手段を提供します。

あなたが SMS 認証を実装する開発者であっても、認証オプションを評価するセキュリティ専門家であっても、または単に 6 桁のコードの背後にあるテクノロジーを理解したいユーザーであっても、この知識は、デジタルワールドをより安全かつ効果的にナビゲートする力を与えてくれます。

---

Latest Articles

Tips, guides, and insights about virtual numbers and online privacy.

View All Articles →

FAQ

Frequently Asked Questions