アカウント名:
パスワード:
充電用のDCコネクターをデータ転送用ポートにしないファームで上書きでOKじゃね？以降の書き換えはできなくなるけどさ
なぜ書き換え出来るようになっているかというと、キーの紛失・盗難等に備えてのことなので、それでは困るホテルも多いはず
組込系でセキュリティというかリバースエンジニアというか、そのあたりのことにいろいろ気をつかってるところはマイコン等の書き換え用のISPやJTAGポートのコネクタのピンアサインを意図的に入れ替えたり、信号の極性を反転させたりとかしてるんですけどねうちはデバッグ用の通信ポートに非同期シリアルではなく同期シリアルを使うことを検討したことがあるけど（今時は同期シリアルにも対応したRS-232Cポートを持っている機器は少ない）
> ピンアサインを意図的に入れ替えたり、信号の極性を反転
この程度の対策しかされてなかったからホテルのカードキーシステムもArduinoで解錠可能になったんじゃないかな？
ピンアサインなんか基板見ればすぐ判るし，同期シリアルでも PICとかArduinoのようなデバイスは簡単に対応できますよ．全然対策になっていません．
ピンアサインとか極性反転程度では，一旦そのカラクリがバレてしまえば，それでおしまいです．全世界のホテル400万室分のデバイスが無意味になる．
ちゃんと公開鍵暗号などで認証を行うようにしてホテル毎に鍵を個別に設定しておけばカラクリがバレても被害は最小限で済んだ筈です．組み込み系の人もちゃんとセキュリティホールに気を使って欲しいものです．
もしWebアプリでプロトコルやアルゴリズムの秘匿をセキュリティです(ﾄﾞﾔｧと称したらフルボッコにされるよねー
で、それらのコストは最終的に宿泊代ということで客が支払うわけですね。
> ちゃんと公開鍵暗号などで認証を行うようにして> ホテル毎に鍵を個別に設定しておけばカラクリがバレても被害は最小限で済んだ筈です．
（錠前みたいなものに一体いくらのコストが許されると思っているかは置いといて）簡単に言うけど、商流や物流のこと考えてないでしょ。物理的な「商品」が流れていくんだから、そんなに簡単な話じゃない。錠前がどういう商流・物流になってるか知らないけど、ホテルごとに設定なんてやったら１）ホテルごとの受注生産になっちゃう２）施工業者に鍵ペア生成と１つずつの書き込み（と管理）をやらせるのどちらかになる。（他にも方法はあるかもしれないけど
まともなところは書込ロック領域のブートローダにファームの署名検証コード入れてると思いますけど？最終製品でデバッガ動かせる場合も最低限秘密鍵で認証後のみにするとかしないんですかね。
16bitデータ長UARTとかもっと変な形式にした方がいいよ。同期式なら普通に売っているが、こう言うのだとFPGAで作るしかなくなる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
これって (スコア:0)
充電用のDCコネクターをデータ転送用ポートにしないファームで上書きでOKじゃね？
以降の書き換えはできなくなるけどさ
Re:これって (スコア:2, 興味深い)
なぜ書き換え出来るようになっているかというと、キーの紛失・盗難等に備えてのことなので、それでは困るホテルも多いはず
組込系でセキュリティというかリバースエンジニアというか、そのあたりのことにいろいろ気をつかってるところはマイコン等の書き換え用のISPやJTAGポートのコネクタのピンアサインを意図的に入れ替えたり、信号の極性を反転させたりとかしてるんですけどね
うちはデバッグ用の通信ポートに非同期シリアルではなく同期シリアルを使うことを検討したことがあるけど（今時は同期シリアルにも対応したRS-232Cポートを持っている機器は少ない）
Re:これって (スコア:2)
> ピンアサインを意図的に入れ替えたり、信号の極性を反転
この程度の対策しかされてなかったから
ホテルのカードキーシステムもArduinoで解錠可能になったんじゃないかな？
ピンアサインなんか基板見ればすぐ判るし，
同期シリアルでも PICとかArduinoのようなデバイスは簡単に対応できますよ．全然対策になっていません．
ピンアサインとか極性反転程度では，一旦そのカラクリがバレてしまえば，それでおしまいです．
全世界のホテル400万室分のデバイスが無意味になる．
ちゃんと公開鍵暗号などで認証を行うようにして
ホテル毎に鍵を個別に設定しておけばカラクリがバレても被害は最小限で済んだ筈です．
組み込み系の人もちゃんとセキュリティホールに気を使って欲しいものです．
Re: (スコア:0)
もしWebアプリでプロトコルやアルゴリズムの秘匿をセキュリティです(ﾄﾞﾔｧと称したらフルボッコにされるよねー
Re: (スコア:0)
で、それらのコストは最終的に宿泊代ということで客が支払うわけですね。
Re: (スコア:0)
> ちゃんと公開鍵暗号などで認証を行うようにして
> ホテル毎に鍵を個別に設定しておけばカラクリがバレても被害は最小限で済んだ筈です．
（錠前みたいなものに一体いくらのコストが許されると思っているかは置いといて）
簡単に言うけど、商流や物流のこと考えてないでしょ。
物理的な「商品」が流れていくんだから、そんなに簡単な話じゃない。
錠前がどういう商流・物流になってるか知らないけど、
ホテルごとに設定なんてやったら
１）ホテルごとの受注生産になっちゃう
２）施工業者に鍵ペア生成と１つずつの書き込み（と管理）をやらせる
のどちらかになる。（他にも方法はあるかもしれないけど
Re:これって (スコア:2)
まともなところは書込ロック領域のブートローダにファームの署名検証コード入れてると思いますけど？
最終製品でデバッガ動かせる場合も最低限秘密鍵で認証後のみにするとかしないんですかね。
Re: (スコア:0)
16bitデータ長UARTとかもっと変な形式にした方がいいよ。
同期式なら普通に売っているが、こう言うのだとFPGAで作るしかなくなる。
Re: (スコア:0)
ですのでドア外にデータポートを設ける理由としては少し弱いです。
おそらく電池切れや故障等何らかのトラブルで強制開錠するために設けた物だと思います。
他社製だとおそらくその用途に使われているような鍵穴があるものもあるので。