タグ: Encryption

XTS-AESが漸く使えるようになったのでBitLockerについておさらいしてみた。

Posted on by S.Kaz

　さて、本日はBitLockerのお話でも。

　Windows10 1511では結構あちこちに手が入っているのは周知の事実。
　その中でも、個人的にはかなりの注目ポイントだと思われるのに、世間では全く取り上げられていないネタが一つ。

　「Windows10 1511からBitLockerでXTS-AESがサポートされた」

　漸くというか何で最初から無かったのといか、そういうレベルではあるが。

　これでBitLockerも漸く「世間並の暗号化強度」と胸を張って言えるようになりました・・・のだが。
　これが世間で全く注目されないということは、やっぱりストレージ暗号化なんて世間では全く流行っていないってことよね、コレ。

　一方で、従来Windows8から使われてきたAES-CBCについて、何だか微妙に誤解されているような雰囲気も。

　ということで、今回はBitLockerの歴史と暗号強度の話でもしてようかと。

　◆

　まず、暗号化ってのは当然ながら強度が高い方がいい。
　但し実際には互換性や処理能力からどこかで「妥協」が発生するので、実際にはこの「妥協」点が適切か、という話になるのですよ。

　◇

　ということで、まずは初代BitLockerから。
　いわゆるNT6カーネル→Windows Vista～7、2008～2008R2にて実装。

　暗号化モードはAES-CBCで128bit（こちらが標準）または256bit、更にElephant Diffuserが標準で付いてくるが、使用しない設定も可能。

　最大の特徴はElephant Diffuserという難読化（というか掻き混ぜというか）アルゴリズムを使っていることで、AES-CBCにおける攻撃耐性の弱さをこれでカバーしている。
　一方で欠点もElephant Diffuserに存在し、何しろコレはAESのような標準化された手法ではないのでハードウェアアクセラレーションが効かず、結果としてBitLockerの重さの主原因となってしまったと言われている。

　ちなみにこの初代BitLockerの詳細についてはMITのサイトに公開されているMSの論文（https://css.csail.mit.edu/6.858/2013/readings/bitlocker.pdf）にかなり詳しく書かれているので興味ある方は一読を。

　◇

　次は2代目BitLockerから。
　いわゆるNT6.1カーネル→Windows 8～8.1、2012～2008R2にて実装。

　暗号化モードはAES-CBCで128bit（こちらが標準）または256bitのみ。
　恐らく速度を優先するために、Elephant Diffuserのサポートをしれっと切ってしまったというのが最大のポイント。標準として使用しないとしても選択肢として残すぐらいしておけば良かったのに、サポート切りってどうよ、と。

　さてそれではAES-CBCの何がそんなにマズいのか。

　先程も「攻撃耐性の弱さ」と書いたが、「特定の状況」では簡単に突破して解読出来てしまうのですよ、AES-CBCって。
　しかもこの「特定の状況」、攻撃者は暗号化キーを知る必要が無いという。

　これだけ訊くと「それじゃ暗号の意味ないじゃん」という方、ちょっと待った。
　この「特定の状況」って、攻撃者は暗号化キーこそ知る必要はないものの、それ以外の状況は結構特殊なんですよ。

　その特殊な状況というのは、攻撃者は暗号化キーは知らないが、最低限復号されたデータにはアクセス可能、というもの。
　個人ベースで一つの環境を占有していればこういう状況には遭遇しようがないが、一方でエンタープライズ系で集中鍵管理やっていたり、家族みんなで同じ環境使ってますなんて環境だと想定しうる事態なんですな。
　そのような状況では、例えば権限管理が甘いor突破されてしまうと、本来読めてはいけない筈のデータが読めたり書き換えできてしまったりする可能性があるんですわ。

　これがAES-CBCの攻撃耐性の弱さなんですな。
　エンタープライズでは複数のユーザーが権限を使い分けるなんて当たり前なので、こんな調子じゃとても許容し辛い。
　なので実際に（ディスクの暗号化が必要な）大多数の企業では、サードパーティ製でXTS-AES等の強度の高い暗号化が出来る専用ツールが導入されていたりするんですな。

　逆に言えば、個人が自分専用で使うUSBメモリのようなメディアなら、AES-CBCでも事実上十分な暗号化強度を持っていまっせ。そういう使い方ならアルゴリズムよりもキーの方の強度を心配しましょう、はい。

　♯いくらAESが突破不能でも、辞書攻撃や総当たり攻撃で暗号化キーがあっさりヒットするようでは元も子もない。

　◇

　そして3代目BitLocker。
　実装はWindows10 1511以降。WindowsServer 2016でも標準サポートしていると思われるが未確認。

　最大の特徴はXTS-AESを採用したこと。
　IEEEで標準化された暗号化アルゴリズムを採用することで、最近のCPUが備えるハードウェアアクセラレーションを活用してElephant Diffuser以上の難読化を高速に処理することが可能となった上、FIPS等の他の規格にも準拠し易くなったという良いことづくめ。
　勿論、エンタープライズの世界でも使い物になる。

　欠点はというと単純に昔の環境では見えないということぐらい。

　ちなみにWindows10 1511以降でしか使用しない前提ならば、XTS-AESを使用した方がAES-CBCより処理速度が速い上、強度も高いので選択しない理由は無い。
　ついでに言うとデフォルトはAES128のままだが、ハードウェアアクセラレーションが効いている環境ならAES256にしても誤差程度しか処理速度に差が出ないので、そちらに変更することをおススメ。

　◆

　最後に、実際の設定方法。ポリシーで設定すること可能だが、個人的にはレジストリで。

　HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE

　EncryptionMethodWithXtsFdv [DWORD]　←固定ドライブ
　EncryptionMethodWithXtsOS [DWORD]　←OS起動ドライブ
　EncryptionMethodWithXtsRdv [DWORD]　←リムーバブルドライブ

　1　→AES-CBC 128 /w Elephant Diffuser （Vista／7 Only）
　2　→AES-CBC 256 /w Elephant Diffuser （Vista／7 Only）
　3　→AES-CBC 128
　4　→AES-CBC 256
　5　→XTS-AES 128 （W10 1511～）
　5　→XTS-AES 256 （W10 1511～）

　ということになっております。
　ちなみにポリシーで設定する場合の場所はここ。

　グループポリシーエディタ（gpedit.msc）起動
　コンピューターの構成→管理用テンプレート→Windowsコンポーネント→BitLockerドライブ暗号化

　・ドライブの暗号化方法と暗号強度を選択する（Windows8、Windows Server2012、Windows8.1、Windows Server2012 R2、Windows 10 [Version 1507]）
　・ドライブの暗号化方法と暗号強度を選択してください（Windows 10 [Version 1511] 以降）
　・ドライブの暗号化方法と暗号強度を選択する（Windows Vista、Windows Server2008、Windows7、Windows Server2008 R2）

　・・・この翻訳の揺れは何。

　◆

　以上、本日はこんな感じで。

Share

さよならCloudFogger、こんにちはBoxCryptor。

Posted on by S.Kaz

　さて、以前から「まだ死なずに済んでいましたか」という感じだったローカル暗号化ソフトCloudFogger、3月にいよいよ命運尽きていたんですな。
　とはいえローカルで使っている分には特に困っていなかったものの、いい加減メンテナンスもされていないソフトウェアを使うのも厳しい。

　ということで、乗り換え先を探した結果、結局BoxCryptorに乗り換えました、という話。
　以下いつものようにぐだぐたと。

　◆

　ぶっちゃけこのテのソフトは今整理統合の真っ最中というか続々と力尽きているというかそんな感じなのだが、選んだ理由は以下の通り。

　・まともに会社としてやっていく気がある
　・ローカル専用暗号化が使える

　こういう言い方はアレだが、CloudFoggerの最大の失敗は「まともに会社としてやっていく気が無かった」ということではないかと。
　純粋にプロダクトがどうかと言われると、そんなに悪く無かったと思うのよね。

　一方で、そこらのサービスで暗号化は出来ていても、当方が大好きな「ZKE」ことZero Knowledge encryptionが本当に実装出来ているかと言われるとこれが実は非常にレアだという。
　理由は簡単で、本気でZKEを実装すると結構手間な上、ユーザーから見ると不便になるという。
　なので大概のこのテのサービスではこの辺りはゴニョゴニョと誤魔化しているんですな。
　この辺りを一番簡単に解決する方法は、そもそも暗号化キーを外に出さないこと。
　ローカル専用で（正しい強度を持つ）暗号化を使えれば、クラウドサービス側から見れば完全なZero Knowledgeになるので、突破は事実上不可能になる。

　ということで、上記要件を満たしたソフトの中でたまたま目についたのが、BoxCryptorだったという。

　このソフト、ZKEを標榜していて暗号化の仕組みも結構詳しくWebサイトに載せており、この通りの実装がなされていればオンラインアカウントを使ってもそれなりの強度は持つものと思われる。
　とはいえ折角ローカル専用暗号化が使えるので、ソレを使います、と。

　UIは仮想ドライブを作成するという、古典的で分かり易い方式。
　キーファイルを予めローカルでコピーすれば使いまわせるので、自分専用の特定デバイスでのみファイル共有が出来ればいいのであればこれで十分。

　一方で、フリーで使える機能は意外と限られており、Dropbox・Box・OnDrive・Google Drive等の中から、特定のクラウドサービス1つだけ。
　複数のサービスを使いたければ年39＄払いなさいな、というビジネスモデル。
　CloudFoggerは基本的に個人使用は無制限でタダだったので、複数のクラウドサービスで使いまわしている人では直接的な代替ソフトウェアにはならないのかも知れないが、自分的にはこれで十分だったので問題無し、と。

　♯この値付けがまた高過ぎないが安くもないという、実に微妙な感じだったりするのだけど。

　◆

　とまぁ、こんなところで。

　♯ZKEといえば、Wualaは撃沈したけどTresoritはフリーミアムモデルで生き残ってるよね、そいえば。SpiderOakは微妙に看板架け替えて完全有料サービス化したけれど。

Share

ディスク暗号化に対する最終にして最強の回答登場・・・か？

Posted on by S.Kaz

　物凄い旧聞ではあるが、何度もネタにしている「ディスク暗号化」について最強とも思えるソリューションがHPから登場してしまったので、今回はそのネタをば。

　◇

　さて、世間ではデータ漏洩やサイバー攻撃に対する興味というか関心は高まってきているが、一方で個人情報保護法をはじめマイナンバー等、最近になってまたストレージ暗号化へのRequireが高まってきているんですな。

　＃それでも全体からすればニッチだというツッコミは甘んじて受けるが。

　で、勿論本気エンタープライズの高～いカネをかければストレージ暗号化なんて昔っから出来たワケだが、もっとリーズナブルな選択肢は無いものか、ということで、以前ネタにしたのがSEDとかHBA暗号化。
　ところがSEDについてはSED対応ディスクの入手性と価格、HBA暗号化についてもRAIDと共存出来ない等、どちらもまぁイマイチ感が残ってしまうというか。

　そんな世界に、HPが最終兵器を突っ込んできましたよ。

　「RAID対応」「鍵管理対応」の「フツーのSATA／SASドライブが使える」「カード上のハードウェアでデータ暗号化可能なRAIDコントローラ」という代物を。

　具体的な製品名はHP SmartArray ControllerのP43x、P73x、P83x世代以降と、Host Bus AdapterのH24x。

　これらの製品はデータをまず暗号化してから処理する（ことが出来る）のが最大の特徴で、Cache上のデータも含めて暗号化されている他、米国の暗号化に関わる認証まで取っているというガチの本気仕様。
　勿論暗号化には追加ライセンスキーが必要ではあるが、これも￥（つか＄）はそこまで高く無い。普通にSEDとか使うこと考えたら十分におつりが来る。

　何より、ドライブの種類を気にせずとも、全てのデータが暗号化されて書き込まれている上に、普通にRAIDでドライブ故障からのデータ保護まで出来るというのは、これはもう「最終兵器」という感じですよ。

　例えば、最近流行のSoftware Defined StorageやHyper-Converged Systemでもストレージのデータ暗号化は（処理）コストが高いため実装されていないモノが殆どだが、このRAIDカードを使うだけでこの問題も突破出来てしまう。
　この一点だけでも夢が広がりまくりですわ・・・うん。

　◇

　とはいえ、所詮HP ProLiantのオプションパーツなので構成やサポートに制約があることや、その辺りはまぁ留意点ではある。
　うっかり自作に使おうとしたら、このテのSASカードは特にコンシューマ向けマザーではウンともスンとも言わないのは良くあることだし。

　＃更に、HPのBIOS・Firmwareの初期モノはクソというオチも付く。
　　後期Firmwareだと問題ないけれど初期Firmwareだとウンともスンとも言わないなんてよくあること。

　更に更にに、HPの12Gbps対応RAIDカードをうっかり自作で使用しようとしてしまった場合一つ物理的なハードルが存在する。それは

　「SASコネクタが独自」

　具体的には「x8 Mini-SAS内部ダブルワイドコネクター」というヤツで、取り敢えずケーブル番号「730603-B21」を買えば一般的なSFF-8087に変換されはするのでサーバ用のHDDケージを持っていればまぁセーフなのだが、そうでないとさて困ったことに。

　・SFF-8087で繋がるHDDケージを買う
　　→一番リーズナブルな選択肢、￥15Kも出せば買える。但し騒音は物凄いことに。

　・SAS Expanderをケーブル中継器代わりにする
　　→騒音がイヤならコレが手っ取り早いが、お値段は結構バカにならない（￥50Kぐらい）。あと、相性問題にも注意。

　ここまでは真っ当なやり方。以下、真っ当でないやり方。

　・外付ドライブ用SASカードを買い（こちらはさすがに世界標準コネクタなので）、 SFF-8644（Mini-SAS HD） to SFF-8482（信号電源一体コネクタ）という変態ケーブルをケース外からケース内に引き込んで配線する
　　→ドライブ台数が8台以下ならある意味アリっちゃアリ。ケーブルがぐるんとしていて見た目ダサいが、USB3.0の黎明期にもあったよねこういうの。

　・SFF-8087で繋がるHDDケージを買って、バックプレーンだけ取り出してSATA延長ケーブルを挿して使う
　　→ノイズという意味で物凄くお薦めしないが、こういう状態を見たことはあるという話。検証ぐらいならセーフ？

　まぁどれを選ぶかは好みの範囲ということで。

　♯ちなみに最下位モデルのH240を買えば普通のSFF-8087ファンアウトケーブルが使えるが、このカードは要するにHBAだということに注意。Cacheも無いし、型番自体「H」だし、RAID激遅だし。

　◇

　それと、HP製品なのでサポート契約が無いとクソFirmwareを更新する手段が無い・・・という話は、どうやらSAS HBAについては対象外の模様。
　詳しくはこの辺りを参照。

　＞http://h30507.www3.hp.com/t5/Technical-Support-Services-Blog/More-information-on-HP-firmware-availability/ba-p/154861#.Vg-2pitp6_4

　要約するとこんな感じ。

　・サポート契約無いとFirmwareを提供しないのはProLiant本体のROMだけ。iLOとかIOコントローラは対象外ね。
　・保証期間が過ぎたらCarePack買ってくれないとFirmwareは提供しないぞ☆
　・セキュリティ絡みとかはタダで公開するつもりから。

　ということで、ファームウェアのダウンロードは問題ない模様。
　実際、モノは試してでファームウェアのアップデータをダウンロードしてみたところ「HP Passportが必須」「サポートサイトの作りがクソで目的の場所に中々辿り着けない」という以外には問題は無かったので。

　＃つーかHP分社化してから更に進んだサポートページのカオス具合はホントどうにかしてくれ。

　P.S.

　余談だがこれらのカードのチップはPMC Sieera製。つまり現行の12Gbps SASチップは本家Adaptecのカードでは有効にされていない暗号化エンジンをチップ内に持っているということ。
　それでも6Gbps世代のMaxCryptoがさくっと販売終了になっていたりする辺り、HBA単体の付帯機能としては全く売れなかったんだろうなぁ・・・と。

Share

BitLockerってWriteが結構重いのね…

Posted on by S.Kaz

　さて、とある事情でデータ暗号化が必須という事態が発生したので、色々なソリューション（←IT業界が大好きな表現）をチェックしていたのだが。
　Windows Serverなら追加ライセンス等不要で使えてOS統合なので（統合管理が不要なら）お手軽、というBitLockerをチェックしていた時に、何だか引っかかるモノがあったので真面目にチェックしてみたのだが・・・。

　BitLockerってReadは兎も角Writeが重てぇ

　ということに今更気づいてしまったのであり。
　具体的には、仮想マシンを使った検証環境の（巨大）ファイルコピーで、以下のようなCPU負荷率の数字が。

　暗号化なし　→　暗号化なし　　8％
　暗号化なし　→　暗号化済み　　19％　（暗号化のみ：＋11％）　　
　暗号化済み　→　暗号化なし　　13％　（復号のみ：＋5％）　　
　暗号化済し　→　暗号化済み　　25％　（復号＋暗号化：＋17％）　　

　♯一応仮想4コア・4GBメモリ・Windows Server 2012R2・Hyper-V。

　以上のように、暗号化の方が復号より2倍近く重い、という実験結果が。
　上記環境で転送速度は大体100～120MB／Sなので、本番環境で要求される数字と比べても控えめなのだが、それでこの数字かぁ・・・と。

　まぁコレを「復号を頑張って軽くした」と評価するのか「暗号化が重過ぎる」と評価するのかは判断の世界だと思うが、一般的なクライアント環境では読込の方が圧倒的に多いので、それに向けてチューンしたという手法自体はまぁ悪くないかと。

　・・・というか、BitLockerってやっぱりクライアント向け実装でないのかね。
　サーバ用途だと（今回想定のように）ガンガン書き込むのが前提なんて特別珍しくもないワケで。
　ん～やっぱりハードウェア暗号化を考えた方がいいかねぇ・・・。

　あ、最後に。
　MicrosoftはHyper-V環境で仮想マシンからBitLockerを使うことをサポートしていません、念のため。暗号化したければホスト側VHDや外部ストレージ側で暗号化しろとのこと。
　とはいえ実際には動いてしまうしちょっと触っている範囲では不具合や制約にも遭遇したことは無いのだが、あくまで検証ですから、ということで。

Share

クラウドストレージを安心して使う為のローカル暗号化、という選択。

Posted on by S.Kaz

　オンラインストレージネタが最近多いが、今回もそのネタで。

　さて、当方の個人的な発想として、信用に足るクラウドストレージなんて代物は存在しない。
　いくら法律があろうが契約で縛ろうが、物理的にデータがそこに保存されている限り必ず自分以外の誰かにもアクセスが出来るし、そのことに自分が気づく手段は無い。

　ということで、当方はクラウドストレージには他人に覗かれてもあんまり困らないファイル以外、原則置いていない。

　♯スマホの写真には時々個人情報が入っちゃっているのが何だかなぁだが、なるべく早く削除してます、はい。

　とはいえ、自動で複数端末で同期するという便利さは捨ておくには勿体ない。
　ということで、当方はCloudFoggerというソフトウェアを使っております。簡単に言うと、ローカルで暗号化してしまうことでクラウドストレージ上でのセキュリティを確保するという代物。
　登場当時は結構あちこちで取り上げられていたので、セキュリティとか気にする人種の間ではそこまでマイナーでは無いとは思うのだけど。

　ところがこのソフト、ベンチャーの製品ということもあるが、公式サイトのblogが2012年で更新が止まっていたり、そもそもベンチャーでは大事なマネタイズの手段が見えない等、継続使用にはかな～り不安感があるのも事実。

　とはいっても、正直このコンセプトは捨て難い。ということで、Alternativeは・・・というと、PKZIPのPKWareが出しているViivoというソフトがあるんですな。
　正直言って着想はCloudFoggerとそっくり、というかほぼパクリ（にしか思えない、こちらの方がだいぶ新しいし）。但しこちらはPKWareという現在進行形で商売しているソフトウェアベンダの製品だし、更にビジネス用途を最初から想定して有料版やFIPS準拠等のオプションがある辺り、CloudFoggerより長持ちしそうに見える。

　ということで、実際に試してみたが・・・結論は。

　「世間的にはOK、でも自分的にはビミョー」

　・・・ということで、もっと具体的な不便や不具合が出る迄はCloudFoggerの使用継続ということで。
　以下、つらつらとどの辺りが「自分的にはビミョー」なのか書いていこうかと。

　◇

　まず、当方はこのテの話をする時は「ゼロナレッジセキュリティ」という考え方をしている。

　SpiderOakやMozy（の高セキュリティオプション）等ではこれがベースになっている、というと偉そうだが、実際には別に難しいことは何もない、当たり前のことをカッコつけて言ってみただけ。

　1. データは脆弱性の無い手法によって暗号化されている
　2. 復号化鍵は手元以外には存在しない（＝他人が知りようがない）
　3. よってデータは安全（＝自分以外には復号不能）である

　たったこれだけ。ある意味暗号化の本質とも言う。

　これをWindows上で簡単に実現するのがCloudFoggerで、選択制でローカルアカウントを作成した時に暗号化鍵は手元にしか無く、正にこの状態になる。ローカルアカウント作成時は必要なのはパスワードのみ。

　さてそうなると次はこのCloudFoggerというソフト自体がどこまで信用出来るかという話になるが、以下が当方の解釈。やや面倒なので読み飛ばし可。

　1. 起動していると1時間に1回程度KeyServerに接続している。従ってKeyServerにローカルアカウントの情報をアップロードすることはいつでも可能。
　2. KeyServerでユーザ特定に使えるのはメアドのみ。他の情報はアカウント作成時に入力してないため。
　3. メアド情報が入っていない鍵情報が仮にアップロードされても、ユーザの特定は出来ない。
　4. 仮に鍵が流出し悪意ある第三者に渡ったところで、この鍵で復号出来る暗号化ファイルを特定不能（或いは特定の暗号化ファイルを復号出来る鍵が判別不能）の為役に立たない。
　5. 以上より、CloudFoggerというソフト自体がSpywareであるというオチでもない限り、セキュリティモデルは崩壊しない。

　まぁ要するに、自分的にはOKということで、当方はCloudFoggerを使い続けていたワケですわ。

　◇

　さてここに来てViivoをビミョーと思った理由。結論から言うと、

　暗号化鍵・復号化鍵・ファイル履歴がしっかりとPKWARE社のサーバに保存されている

　ので。
　対するCloudFoggerは、鍵も情報も一切外に出さない（ことになっている）ので、どちらが安全かと言われると圧倒的後者。

　＃というか、セキュリティ的な発想で言うと一切サーバに接続しない使い方「も」サポートするのが当然だと思うのだが、何故にそうなってないのさコレは。

　復号化キーは別名「秘密鍵」なので、コレがサーバ上にアップロードされてるってのはさすがにどうかと。
　勿論何らかの方法で、というか恐らくメアドとパスワードをキーにして暗号化されているのだろうが、それでもアップロードされていること自体どうなのさ、と。

　勿論、この方法にもメリットはある。
　複数のクライアント間で同一アカウントを使う場合（モバイルとデスクトップ等）、CloudFoggerではローカルの復号化鍵を何らかの手段でコピーする必要があるが、Viivoではアカウントさえ間違えなければシームレスに運用は可能。
　恐らく昨今ではセキュリティ的な完璧を求めた故の不便さより、ある程度脆弱になるのを覚悟してでも利便性を取った方がウケるだろうから、こういう仕様にしたのでしょうな、というのが当方の解釈。

　まぁ、登録するメアド・パスワード・ユーザIDは他では一切使用していない、連想も出来ないものにしておけば、仮にPKWARE社のサーバからアカウントや鍵情報が流出してもその鍵で復号化する暗号化ファイルを特定出来ない（逆方向も可）ので事実上役に立たず、セキュリティは保てる。

　そういう意味で、ユーザが正しく使えばViivoもかなり強い防壁となり得るのだが、それでも「ゼロナレッジセキュリティ」信奉者としては「何だかなぁ」という感覚が捨てきれない。

　ちなみに上記の鍵情報がアップロードされていることは、以下の作業で確認済。

　1. 検証用仮想マシンAの上でインストール、アカウント作成、暗号化ファイルα作成。
　2. 検証用仮想マシンBの上でインストール、アカウントログイン。
　3. この時点でBのViivoマネージャ画面には（Aで作業した）暗号化ファイルα作成履歴が表示される。
　3. AからBへ暗号化済ファイルαをコピー。
　4. Bマシン上で暗号化済ファイルαを復号、正常完了。
　5. Bマシン上で別のファイルβを暗号化。
　6. BからAへ暗号化済ファイルβをコピー。
　7. Aマシン上で暗号化済ファイルβを復号、正常完了。

　Step3で履歴情報がアップロードされていること、Step4で秘密鍵である筈の復号化鍵がアップロードされていることが確認出来る。

　◇

　まぁここまでつらつら書いてきておいて、カッコ悪いオチを一つ。

　当方、個人メールはApps for Domains（旧称）に集約しているし、Google Calenderはフル活用しているし、ということで、今更ファイルだけ暗号化したところで既に個人情報ダダ漏れ状態ではあるんですよ、実はね。

　とはいえ、過去にはデータ流出に近いポカを実際やらかしたクラウドストレージも存在するし、個人情報というのは密度が大事なので、その密度を増強する強力な要素たり得るファイルを暗号化をしない理由にならない、というのが当方の考え方。

　何より、初期セットアップさえ済んでしまえばその後はそんなに面倒なモノでもないし。
　そりゃまぁこれが毎日イライラする程不便だったら、また別の結論になったかも知れないけど。

Share