しつこく書いていますが、Securityが大事！という点に関しては否定する方は居ないでしょう。

では何故、Seruciryが大事か！？と問えば、

『データのセキュリティは当たり前だ！』と言うことになりますよねｗ

IoTで扱うデータもそれは社内データでもありますので、当然セキュリティは重要です。

ここまでは、私が講釈する必要も全く無いでしょう。
セキュリティレベルも様々で、家の鍵も同様に進化してますし、インターネット上のセキュリティ鍵の重要性は高まっていますよね。

最近では、IoTに置いても行政が介入し『セキュリティ認証』とやらも承認がいるとか。。。もうね～～～ｗ

と・こ・ろ・が

私は、「なんでそんなに騒いでるの？　騒ぎすぎだろ？　ハッカーが～！ってｗ　侵入できんってｗ　侵入しても意味無いでしょ？」
とずっと思っていまして、ここがずっと疑問でした。

『技術視点のセキュリティそもそも論」というのに気付いたのです。
コレについてはちゃんと説明している人や書籍の類いは、知らないです。

この回では、そう言う弊社独自の『セキュリティ論』について記載します。
この見解は、インターネットに詳しい技術者達も同意しています。

まぁ、インターネットの世界には悪い人も存在します。
犯罪に使われたり、ハッキングやら、色んな『悪さ』がありますよねｗ

そう言えば、『自宅の鍵』についても、簡単に複製出来るモノもあれば、複製が難しいモノもありますし、10桁数字のデジタルキーもあります。
私の実家の『鍵』などは、簡単に複製可能なモノですが、侵入されたことは有りません。

インターネットの世界で、IoTデータにも厳重なセキュリティの必要性が声高に言われています。要求もされます。

私の見解
『ソフトウェア業界が《テキスト通信》をしている事が”そもそもの問題”』

って事です。
では解説して行きます。
 

そもそも『通信』とは2つ（又は複数）間の間で、コミュニケーションをすることです。
かつては、トランシーバーや固定電話も通信機です。
今では、携帯電話でデータを相互間で交換しますのでこれもデータ通信です。
古くは、テープレコーダーや、レコード盤や、CDやDVDも有る意味『通信』だと思ってます。
時間差はありますが、郵送して親に孫の動画を送ったりもしますので、『通信』でもあります。

そして、勿論IoTも通信です。

インターネットに関しても、インターネット通信ですね。

ここでは、インターネットの世界に絞って考えます。

インターネットは世界中のユーザーが、共通の通信仕様（プロトコル）に基づいてデータを通信しあっています。
ここもなんとなく分かると思います。
共通だからこそ、世界中で情報共有が可能なのです。だから『共通の通信仕様』に基づいて相互通信を実現しています。

これを
HTTP通信
で行っています。

ホームページのアドレスは、《http》で始まっていますから、ご存知の筈です。
あれが、HTTP通信ですよ！という宣言です。

HTTP=Hyper Text Transfer Protocolの略です。
日本語にすると、
《ハイパーなｗテキスト通信のプロトコル》ってことに成ります。そして世界共通で使われます。

『Text：テキスト』って何の事？
ココが今回のテーマです。

実はこれ『文字通信』の事なんです。それでも「？」って成りますよね。

英語圏ならば、『英数字通信』と言うこと。
日本語圏ならば『日本語文字通信』と言うことを言ってます。

まだ、？ですよね。もっと詳しく書きますと
『ASCIIコード通信』
と言うことです。ではASCIIコードとは。。。

私は30年以上前の学生時代から『ASCIIコード』というモノが存在していた事は知ってましたが、当時有った『アスキー出版社』が作ったモノ
と最近まで思い込んでましたｗ　

ASCII＝American Standard Code for Information Interchange
だそうです。

つまりは、デジタルで文字を通信する場合の『コード表』であり、『暗号表』みたいなモノです。

文字情報をそのまま通信することは不可能なので、この『コード表』に基づいて、『コード』のみを送受信して、元の文字を『復元』しています。

ASCIIコード表は『暗号表』みたいなモノと表現したのは、昔昔。。。無線通信においては『モールス信号通信』というのがあったんです。
私と同世代の方は知ってますが、若い方は知らないと思いますｗ
「トン・ツー・トン・トン」と短音『トン』と長音『ツー』の2値を使います。
『モールス信号のコード表（暗号表）』で文字を『2値を使ったコード列』変換しに無線で送信します。

そして、受信した側は『コード表（暗号表）に基づいて、『文字列』を復元していたのです。

日露戦争時の連合艦隊の主戦艦『三笠』でも使っていたので、1905年には最新の通信手段として採用されてます。もう100年以上も前です。

これが元々、『デジタル通信』の始まりです。

そして、パソコンというのが生まれてからは、英語圏でASCIIコードを作成し、標準化された『コード表』を今でも使っていると言うことです。
1963年に規格化されたみたいです。

実際のコード表を貼ります。

この『ASCIIコード表』をどう使うのか？　って事は気にしなくて良いですｗ　そういう『コード表』を使っているんだな～程度でOKです。

ちょっと余談ですが、
『bit(ビット)』
って聞いた事ありますよね。　
HDD（ハードディスク）の容量は10Gbitとか、娘達は「ギガが足りない‼」とか言ってますｗがあれはスマホの一月辺りのデータ使用量ｗ

チョットマッテください、HDDは10GB（ギガバイト）だぞ！　bit(ビット）じゃ無いぞ！って成りますよねｗ

そうです、『Byte(バイト）』って単位も良く聞きます。

これは、

『1Byte=8bit』

というルールが有るんです。
※なんと2008年に正式に基準化されたんだそうです。それまでは常識として運用されてました。

凄く一般的では無い単位で難解です。
10GB：10ギガバイト
10Gb：10ギガビット＝10Gb/8=1．25GB（ギガバイト）　※1バイト=1ビットなので1/8したらバイトになります。
と大文字と小文字で判別します。

なんだか、セキュリティとは全く関係ない方に行ってるように思えますがｗ　大事な話です。

表をよく見ると、「0～7：8桁」のbitsという表記が観えますね。

ここまで分かりましたでしょうか？
8bit(=1Byte)で、アルファベット大文字・小文字、数字、その他が表現出来てます。

チョット待て！！！！！日本語はどうするんだ！と思われた方も居られるはずですｗ

英語圏は数字と英文字の小文字と大文字だけだが、日本語はひらがな50音、カタカナ、漢字もあるのにどうするんだ？？
と言う疑問がある筈です。
これは
JISコード（ISO-2022-JP）という形で定義されています。1Byteでは足りないので、2Byte=16bit表になります。
興味のある方は、調べてみてください。観る気を失いますがｗ
2Byte=16bit=8bit x 8bit=65,536種の表現ができますので、漢字にも充分に対応できます。

基本、ここの解説ではASCIIコード（英数字）ベース（1Byte)で解説を進めます。

100年以上も前の『モールス信号通信』に始まり、今では『インターネット通信』も広がった事には、
最終的には『ASCIIコード表』が存在することの『お陰様』でもありますよね。

これが無ければ、世界中相互間のオープンな通信は出来ませんから、素晴らしい『定義』です。。。。

インターネットの世界でも、このASCIIコード表に基づいて通信が為されています。

しかし、

だ・か・ら！大問題なんです！！！
　
 

さて、デジタル通信はASCIIコード表のお陰様で、便利なインターネットの世界が構築されているわけですが、
それが大問題とはどう言う事でしょうか？

世界中が『ASCIIコード表』に準じた、テキスト通信をしているからこそ便利なんですが、

それ。。。皆が『ASCIIコード表』を持っているからこそ、簡単に傍受されるって事なんですｗ

良く良く考えれば、当たり前ですね。

だから、旧大日本帝国の連合艦隊で使われたモールス信号もASCIIコード通信（当時は無いですがｗ）をしていたら、
簡単に敵に傍受されてしまいますよね。　傍受されたら、作戦すらも筒抜けですｗ

だから、当時の通信でも、
『独自のモールス信号表』を秘匿された暗号表を、お互いのみが秘密に持っているワケです。

100年以上前から、そう言う使い方『セキュリティ』を掛けて運用していたのです。

そして、今ではインターネット通信でASCIIコード通信を当たり前にやっており、その表は一般的に公開されています。
そのままでは、一切『セキュリティ』が掛かっていないと言うことです。

グローバルでオープンに使われるべく『ASCIIコード』に基づいて通信されるから便利なんですが、それだから『秘匿性』が無くなる。

と言うことなんです。

だ・か・ら！

『Securityを掛けなければ成らない』

と言うことなんです。
そして、時と共にSecurityレベルをドンドン上げていかねばならないと言う事態です。

ここで、ちょっと大事な話をします。

ソフトウェア業界：もうインターネットが当たり前の世界。ASCIIコードで通信をするのが当たり前の業界
ハードウェア業界：もともとASCIIコードなんか使わない業界。ASCIIコードなんか不要な業界

これまでのIoT＝サーバーにビッグデータを貯めさせる＝クラウド使用料を継続課金可能。

まぁ、十把一絡げに言いますと、IoT業界というのは、元々こういう基本構造で始まったと思っていて問題無いと思います。

私はずっと『ハードウェア業界』でやって来ましたから、このIoTが定義には、当初から穿った見方をしていますｗ

というのも、当初からサーバー屋さんが特にIoTを盛んに主張し大騒ぎして盛り上げようとしているような、『気』がしてました。

私は「何でもかんでもデータを掻き集めて、サーバーにビッグデータを貯めさせて、サーバー使用量を増やして儲けようとしてないか？」
と言ってましたｗｗｗ

し・か・し、
喧伝されているIoTには穿った見方をしていましたが、確かに『IoT』は活用すれば、第1章ｰ1で書きましたように、
　①人材不足解消
　②リソースの合理化
　③リソースの少人化（人の関わりが必要な作業の削減）
には圧倒的に便利で有利になるとは思っていました。

でも、しかし。。。この定義のままでは、

『ASCIIコード表』をマイコンに持たないとダメなんです。
そして、『ASCIIコード』に基づいたテキストデータで通信するなんて言われても。。。
毎度毎度マイコンのプログラムが、内蔵した『ASCIIコード表』と照らし合わせて文字を復元したり、ASCIIコードへ変換したりと。。。
こんな処理は、マイコンでは無理なんです。

オマケに、当初から『Security』に関しては五月蠅く、ソフトウェア業界の暗号化までしないといけないとかいっても
マイコンでは無理なんです。

そもそもマイコン（MCU）というのは、プログラムコードを1行ずつ順番に処理していくんです。
パソコン等はOS（WindowsやiOSやLinux)が有るので、同時並行処理が出来る様になってまして、全然作りが違います。

どうして2つも方式が違うんだ？と
それは、分かり易く言いますと、
OSを持ったコンピューター（OSを使うのとCPUと呼び、マイコンのMCUと区別します）、ってのはOSがずっと動いていますので、
低消費電流なデバイスなんか作れないんです。

一方、
MCU（マイコン）ですと、消費電力は0.003ｗ(ワット）以下で動きます。だから、乾電池やボタン電池でも動かせます。

そもそも、家電等にはCPUを使うなんて大げさで、MCU（マイコン）で充分なんです。
※最近はCPUベースで作られている家電もありますが。

なので、
MCU（マイコン）では、ASCIIコード表を参照した処理や、厳重なSecurityを掛けた処理は難しいのです。出来ないと言って良い。

なんとなくですが、大雑把に言いますと、
こんな感じで理解されておれば大体当たっていますので、この位のレベルで理解されておけば良いと思いますｗ

『ソフトウェア業界が、IoTでやろうとしている事』と
『ハードウェア業界が、IoTで出来る事』のギャップは（今の技術では）埋められないんです。

『ASCIIコード表』を使って、且つ『厳重なセキュリティ』も必須で、ハードウェアを作ったらCPU（OS動作)構成しないと実現不能。
しかし、それでは電池駆動なんて無理筋です。

はい、詰みましたｗｗｗ

だから、IoTは巧く行かないんですｗｗｗ

***********************************************************************************************
ちょっとインターネットには詳しい、技術系な方向けに追記しますと、
厳重なセキュリティの為にと、サーバー企業側が厳重なセキュリティ確保の為に『クライアント認証』とが必須に成ってますよね。
スマホも全て、この『クライアント認証』を都度必ず実行しています。
そして、この『クライアント認証』は期限が決められており、有限です（サーバー企業はその有効期間を更に短くしてます。2年毎→1年毎の様に）。
電池駆動できるMCUベースでIoT機器を作った場合も、インターネットサーバーに繋がりますので、この『クライアント認証』は必須です。

もはや、
『厳重なSecurity』と『ASCIIコード通信』の2つを必須ですが、マイコンでは100％実装不可能です。
*************************************************************************************************
ラズベリーパイなんかは、Linux(OS)で動いてますので、プログラム容量も無限領域です。
そして、『クライアント認証』を実行する様なプログラムもオープンソースで公開されているでしょう。だから簡単です。
所が、MCU（マイコン）でこの『クライアント認証』のプログラムなんか、作れないんです！
オープンソースでも存在しません。しかも猛烈に難しい超難易度の高いプログラムになり、大容量サイズになります。
そう言う事が現実なんです。
*************************************************************************************************
 

『IoTの実現』とは、ソフトウェア業界の方が言う程、『簡単』では無いって事を理解して頂けましたでしょうか。

大体、ソフトウェア業界の方々が他業界の領域について語ると「簡単」と思い込んであるケースはとても多いです。
ちょっと謹んで頂きたいと思います。

この大問題を解決するには、大変な考察とノウハウと理論が必要になります。
私達Braveridgeでは、14年に渡るIoTの経験から1つの『提案』に行き着きましたので、『1つの解決案』として検討してみて下さい。

『ASCIIコード通信』を止める！！
そもそも、ハードウェア業界はASCIIコードを使っていません。
無線通信においても使っていません。

ハードウェア無線通信の世界では、ではどうやってデータ通信をしているのか？ということですが、

『バイナリー通信』

を普段から使っています。
バイナリー通信とは、データの生データそのものです。
センサーから取得された情報は（ほぼ）、1Byteや2Byteや3Byte程度のデータです。
1Byte=8bit=256種の表現が可能→[01001101] の様な、当にデジタル信号です。
2Byte=16bit=65,536種の表現が可能　※JISコードの2Byteコードで漢字も扱えるのはこう言う事です。

たとえば、温度センサーのデータであれば、8bit=256段階の温度をデジタル表現できる1Byteで充分でしょう。
25.6度ってのも1Byteで表現できます。
一方、ASCIIコードで表現すると、
2（1Byte)-5(1Byte)-.(1Byte)-6(1Byte)-度（2Byte)＝6Byte
にも成ります。6倍です。

では、刻々と変わりゆく温度を通信した場合を想定してみましょう。
まぁ1秒毎と仮定します。
バイナリ通信ならば、1秒毎に1Byteで充分です。
ASCIIコードで通信したら、1秒毎に6Byteです。

時間が経てば経つほど、この6倍のデータ通信量の差は累積されますよね。
それだけ、LTE通信データ量も増えると言うことです。通信費用も掛かります。

では、加速度センサーを想定します。
バイナリ通信ならば、X-Y-Z軸それぞれ1Byteなので、合計3Byte
ASCIIコード通信ならば、各軸あたりを文字データに変換しますので、ちょっと良く分かりませんが、その3軸分となると膨大です。
6倍どころの差では無いです。何十倍もの差に成るでしょう。
これを、モーターの振動を検知して、故障予測なんかしようとすると、1秒間に10回以上は通信しないとダメでしょう。
これをずっと動かし続けていると。。。LTE通信データ量はもう月額数百円では済まなくなります。そう言う事です。

少し、技術的に踏み込んで話しをしてますが、大体、イメージは付いて来れてますでしょうか。
大丈夫だと信じますｗ

ようするに、ASCIIコード通信と比べれば、同じ内容を通信したとしても数倍~数十倍のデータ量の差が有るのです。
累積するとトンでも無い差に成ってきます。

コレでやります？ｗ　やりませんよねｗ

だから「ASCIIコード通信を止めましょう」と提案しているワケです。私共にはコッチの方が100倍楽ですしｗ

バイナリ通信でやると想定してみましょう。
セキュリティを一切掛けてないと仮定します。

悪い人が、それを傍受したとします。

そこには
[01001110101011010101010101011111011100000100000111010111101........]
とセキュリティを掛けてなければ、完全に傍受されます。最悪ですね。

では、これ何のデータなのか？特定出来ます？？？ｗ

100％無理ですｗ

温度計のデータ？加速度センサーのデータ？しかもX-Y－Zどの順番のデータ？湿度計のデータ？
そもそもセンサーのデータなの？IDなの？製造設備のステータスのデータなの？
オマケに、どこから何どこ迄がデータ？何のデータ？

全てに於いて解読出来ません！

何のデータなのか？が解って居るのは、このMCU（マイコン）のプログラムを作成した一人（1組織）だけです。
当たり前にフォーマットして通信しますが、そのフォーマットは設計者しか知りません。
これでどうやって、データの意味を解読出来るでしょうか？　100％無理です。

つまり、
プログラム開発者のデータ・フォーマットこそが『暗号表』になっているわけです。

この方式の方が圧倒的にSecurityレベルが高いと思いませんか？
どんな凄いエンジニアでも、AIでもこれを解読することは不可能です。

Security（暗号化）としては最高では無いでしょうか？

勿論、プログラム開発者の『データ･フォーマット』が存在しますので、それが流出すれば解読は出来ます。
※ソフトウェア業界においては、開発者が設定する『パスワードみたいなモノ』すらも、秘匿化しているようです。
　それに比較すれば、流出のリスクがある『バイナリ通信』も完璧では無いと言えばその通りです。
　しかし、そんな複雑なソフトはMCU（マイコン）には実装プログラム出来ないのです。
 

バイナリ通信の弱点は、プログラム開発者の持つ『データ・フォーマット』の流出が懸念点です。
開発者従属のセキュリティとなるからです。

そもそもデータそのものは圧倒的に秘匿性が高いですが、『データ・フォーマット』が流出すれば、終わりです。
開発者従属の『パスワードみたいなモノ』に依存するからです。

これはどうにか出来ないモノでしょうか？

ここにも1つ案があります。
よく知られている
暗号化技術『AES-128』を使ってデータの暗号化を掛ければ、ほぼ大丈夫と思いませんか？

これで、傍受の方のセキュリティを掛けられます。
AES-128とは128bit長の暗号鍵を使ったAES(Advanced Encryption Standard）暗号です。
　※2000年に米国立標準技術研究所(NIST）によって標準化されています。
普段のインターネット通信でも使用される暗号で、もっとも短いAES暗号鍵ではありますが、一般的に使われています。
ZIP圧縮ファイルやSSL/TSLとかもコレです。
※SSL/TSLというのは、インターネット上で良く使われている程度の理解でOKです。

そして、
これはBluetooth®通信に於いては、一般的にICチップの中の回路として実装されていますので、採用は簡単です。

如何ですか？

良く勘違いしている方がとても多いのですが、暗号鍵の長さでのみSecurityレベルを判断する方が多いので困ってます。

「128bit長の暗号では安心できない！」
「192bit長でも充分ではない！」
「256bit長でも安全とは言われてない！」

と言われる事も多いです。
そこで、私は
「それなら512bit長では？」→「いやいやそれでも充分ではない！」
「それなら1024bit長にします？」→「どのレベルの暗号長であれば、安全なのかは言えない！」

と、これ実際に私が経験した会話ですｗ

心の中では
「（あの～～～512bit暗号なんて無いんですけど～。。。ましてや、1024bit暗号長なんかあるわけないｗ）」と思いましたｗ

こんな議論は珍しい事では有りません。

つまり、
『暗号化』という言葉だけで、暗号化とは何かも分からずに、もはや考察・判断だけが暴走していると言い切ってもよいと思います。

「Securityは重要だ！」と声高に言われる方自身が、そもそも『Securityは何をいかに暗号化して、秘匿するべきなのか」という
理解をせずに世の中が突っ走っている事が問題だと思います。

先の実際の会話で、最後に私が相手に言った言葉を、
「あの～送っているそもそものデータは8bit(=1Byte)なんですよ。その中でも1bitしか使ってません。そこに256bit長の暗号をかけれ
なんて話ですが、たかが1bitデータ送っているのか?256bit長の暗号鍵を送ってるのか？　殆ど暗号鍵を送ってる状態では？ｗ」

如何でしょうか？

暗号化！秘匿性が！暗号鍵長が！

って話ですが、そもそも論として分かって居無い方々の非技術的な大騒ぎな面も有ると言うことです。

それでも心配だとは思います。
しかし、『バイナリ通信＋AES-128暗号鍵』で充分なのでは無いでしょうか？

本音では、『バイナリ通信』だけで、充分に秘匿性の高い通信なんですよね。