ナビゲータのEVEです。
歯が抜けました。
若い頃、神経を抜き、抜歯後数年経った頃から具合が悪かったので、こんなことはあるかもしれないとは思っていましたが、ショックです。
寝る前必ず、フロスで歯をクリーニングをします。その時、抜けてしまった歯の、かぶせモノと自分の歯の間をきれいにこすっていたのですが、ワインコルクが抜けるがごとく、スポンと抜けました。これって、直すことできるんですかね?明日歯医者で診てもらいます。本当にいろいろとあります。やりくりがいろいろと大変です・・・。
では、本日は、DiXiMのセキュリティについて調べていきます。
[DiXiMによる自宅と自宅外の通信]
一応、設定前に、AIに同ソフトの安全性について、聞いたのですが、解答は、安全ですとのこと・・・。そのため、設定当時はあまり気にしなかったのですが、箱根で、実際に、自宅とビデオを見ていて、なんだか心配になりました。
それは、自宅のビデオは、宅内のルーターの内のFW内に設置しています。そのFW内のビデオと通信ができる状況は、ハッカーが標的者攻撃で、ウイルスを送り込んだ後の状況と同じです。このような心配は、DiXiMの仕組みを知らないから心配なのであって、その仕組みを知れば安心できるかもしれません。では、まずは、ペアリングする場合の方法について確認してみましょう。
| 層 | 内容 | 目的 |
| 1 | デバイスID登録 | 正規端末として認証 |
| 2 | 暗号鍵交換(DTCP-IP RA) | 暗号化ストリームの復号権限を付与 |
| 3 | 中継サーバー登録 | 宅外から接続できる経路を確保 |
| 4 | 利用制限情報の同期 | 著作権保護ルールの適用 |
以上のペアリングを経て、外部からアクセスする場合、どのような流れになるのでしょうか?以下がその流れになります。
↓(暗号化)
中継サーバー(DiXiM)
↓(暗号化)
自宅レコーダー
以上の流れでは、どのようなセキュリティが施されているのでしょうか?
- 1. 端末認証(Device Authentication)
- デバイス証明書(Device Certificate)
- 相互認証(Mutual Authentication)
- 端末ID登録(ペアリング)
- 2. 公開鍵暗号による鍵交換(Key Exchange Security)
- RSAまたはECCによる公開鍵暗号
- 秘密鍵は端末内に保持され外部に出ない
- 鍵交換後はAESで暗号化通信
- 3. コンテンツ暗号化(Content Protection)
- AES(共通鍵)によるストリーム暗号化
- DTCP‑IP Copy Control Information(CCI)
- 中継サーバーは復号できない
- 4. 通信経路の保護(Transport Security)
- 暗号化されたトンネル通信
- 中継サーバーは“経路提供”のみ
- NAT越えのための安全な中継
- 5. アクセス制御(Access Control)
- 端末ごとの視聴権限管理
- 同時視聴数の制限
- 宅外視聴の画質制限(機器による)
- 6. 中継サーバー側のセキュリティ(Relay Server Security)
- 認証情報の管理
- 通信内容は暗号化されており復号不可
- ログ管理による不正検知(一般的なサーバー側対策)
- 7. DRM(著作権保護)レイヤーのセキュリティ
- DTCP‑IP規格に基づく厳格なDRM
- デバイス証明書の失効(Revocation)
- コピー制御情報の強制適用
そもそも技術的にちがうものですが、インターネットショッピングと比較すると、セキュリティレベルは低いが、一般的なハッカーに対しては強固であるという回答になるようです。但し、中継サーバーがハッキングされた場合などの脅威があるということは念頭に入れておいた方がいいようです。
[あとがき]
まっ、たまに利用する場合などはいいかなって言う感じです。ただ、リスクが1つ増えることになるので、宅内のセキュリティレベルは下がったと考えた方がいいでしょう?そのリスクを理解し、利用することをお勧めします。
以上の調査を経て、ビデオデッキの配置セグメントを検討します。
今週のセキュリティ通信は気になるテーマがあったので、そちらは優先しましたが、来週は、アスクルでのランサムウェア攻撃に話を戻します。
では、また!
コメント
コメントを投稿