OpenSSHにメモリ上の暗号鍵を暗号化する機能が追加される 34
ストーリー by hylom
暗号鍵のための暗号鍵 部門より
暗号鍵のための暗号鍵 部門より
Anonymous Coward曰く、
昨今ではCPUのキャッシュ機構を悪用するサイドチャネル攻撃手法がたびたび発見されているが、OpenSSHがこういった攻撃への対策として暗号鍵をメモリ内で暗号化する手法を導入するとのこと（OpenBSD Journal、マイナビニュース）。
新たな緩和策では、16KBの原始鍵（prekey）がメモリ上に置かれ、通信に用いる秘密鍵などの鍵はこの原始鍵によって適宜暗号化・複号される。理論上はこの鍵もMeltdownやSpectreなど一連のサイドチャネル攻撃によって盗み出すことが可能だが、データ量が大きく、また求められる精度が高くなるため、攻撃の脅威が緩和される仕組み。
アナウンスは「願わくば数年のうちに計算機設計が多少は非安全でなくなり機能が除去できることを」と締めくくられている。
「多少は非安全性がなくなり」 (スコア:0)
> 多少は非安全性がなくなり
なんだか奇妙な文だね。
元の文はこれだと思うけど、
ん？「多少は」ってどこから来てる？
ちなみにマイナビ記事だと思い切って超訳してるね。
Re: (スコア:0)
「become ... unsafe」を「非安全性がなくなり」と訳しちゃったから、lessの行き場がなくなって「多少は」になったのかな。
「非安全性が減り」で良かったと思う。
Re:「多少は非安全性がなくなり」 (スコア:1)
そもそも、「非安全性がなくなる」も「非安全性が減る」も日本語として不自然なんだから、
「より安全になれば」とかに言い換えるべきだと思う。
Re: (スコア:0)
一方、グーグル先生は「安全性が低下したときに」と、自然に訳してくれた・・・・って、ナチュラルに意味が変わってるやんか！
Re:「多少は非安全性がなくなり」 (スコア:1)
Google先生は否定表現が重なると苦手らしい。しれっとひっくり返して訳してくるので要注意。
Re: (スコア:0)
ディープラーニングの「お手本」が苦手にしているということだぞ
Re: (スコア:0)
皮肉一杯にするためとかニュアンスを盛るために意図的に妙なフレーズを使った、とかだと言い換えるべきでないかもしれないし、難しい。
「become safer」だと「より安全になる(今でも十分に安全かも知れないし、そうじゃないかも知れないけど、そこはどうでもいい)」だけど、「become less unsafe」なら「(今は危険だと断言した上で)より危険が減る」というようなニュアンスが付きそう。
Re: (スコア:0)
その表現だと現状がunsafeであるという認識が含意されなくなるのであまり適切でないと思いますね。
Re:「多少は非安全性がなくなり」 (スコア:1)
「あと数年の間に計算機のアーキテクチャがより危険でないものになれば、この機構をなくすことができる」ってところですか。
Re: (スコア:0)
訳者っす。その節に含まれる見下し目線を再現できる方法がなかったので。
Re: (スコア:0)
つまり「どうせできないだろうけど」が行間に含まれてるわけね
Re: (スコア:0)
近いうちに脆弱性の多くが解決しこの機能が要らなくなることを願っている
とかでしょうか。
Re:「多少は非安全性がなくなり」 (スコア:1)
「数年くらいでコンピュータアーキテクチャのヘボみが減って、コレを取り除けるようになってくれると嬉しいんだけどね」
これじゃ砕けすぎか
Re: (スコア:0)
・・・・」と、皮肉をこめて締めくくっている。
明記すれば良いんじゃないでしょうか。
Re: (スコア:0)
そもそも皮肉なんですかね？
メモリまで信用できない時代か (スコア:0)
メモリまで信用できない時代か、というのも今更なんだが。
今後きちんと対策できるものなのかな。
クラック手法として実用化はほぼされない一方、概念実証と対策のいたちごっこがしばらく続くんじゃなかろうか。
とりあえず緩和策としてはやらないよりマシ程度に見えるけど、攻撃する側としては難易度は桁違いではないかと思う。
散々苦労して暗号鍵っぽい物を見つけ出したと思ったら暗号化されててさらにも一つ鍵を見つけるってのは相当辛いんじゃなかろうか。
余りスマートではないが。
Re:メモリまで信用できない時代か (スコア:2)
サイドチャネル攻撃自体は昔からあるんだけど、
・高確率で実現可能なコードはすくなかった
・クラウドサービスなどで、関係の無い他者が同一ハードウェア上で同居することが一般的になった
ってのがデカイです
[Q][W][E][R][T][Y]
Re: (スコア:0)
CPUが発するノイズ音や電磁波で攻撃可能な時代です
Re: (スコア:0)
一応OS側でメモリを暗号化するものもある。ほかプロセスのデータは読めないみたいなやつ。
Re: (スコア:0)
キャッシュラインにのる時はすでに複合化されてんでないの
Re: (スコア:0)
CPUでやるならメモリアドレスに応じて適当にNOT掛けるだけでもそこそこ効果的そう。
「読み取れているけどどこを読み取っているのか分からない」という状況に限るけど。
実際古い簡易DRMというか難読化だとよくあるパターンで、ヘッダとかみて判断するけど途中だと絶対分からん自信がある。
Re: (スコア:0)
概念的に安全って言えば、例えば公開鍵とかがあると思うんだけど、あれって双方向通信であることを上手く使うからこそ安全がたもたれている。
メモリを現在のプロセスから未来のプロセスへの通信経路だと考えると、現在から未来への通信はできても、未来から現在への通信はできない。これを解決できたらタイムパラドックスになってしまう。だから、一方向通信であることは避けられないし、ボトルメールの中に宝箱を仕込んでも鍵を同封せざるを得ない。
Re: (スコア:0)
何の根拠もないが、経験的に、これまでの攻撃方法の難易度が上がった反面、新たな脆弱性を生んでいるような気がする。
というか、復号しないと使えない暗号は本質的にサイドチャネル攻撃に弱いと思う。
暗号⇔復号 (スコア:0)
よく覚えておきましょう。
Re:暗号⇔復号 (スコア:1)
「平文(名詞)」を、「暗号化(動詞)」したら、「暗号文(名詞)」になり、
「暗号文(名詞)」を、「復号(動詞)」したら、「平文(名詞)」に戻ります。
このシステム全体を示すのが「暗号(名詞)」。
「暗号⇔復号」という対応はありません。よく覚えておきましょう。
もうちょっとましな訳語をつけて欲しかったと思わないでもないが、もう仕方が無い。
Re: (スコア:0)
コンピュータサイエンス用語としての復号(decode)の対義語は符号化(encode)だと思うけど、
暗号化(encrypt)の対義語のdecryptの和訳も復号でいいのかなとも思ったり。
Re: (スコア:0)
辞書では「復号する，解読する」と出た。
# 確かに状況によっては「解読」か
Re: (スコア:0)
解読って書くと、少し正規の方法以外で復号するイメージがあるなぁ。
Re: (スコア:0)
それもわかる気がするが、軍隊とかで暗号文で指令が来たら
「復号急げ!」とかより「速く解読しろ!」とか言いそうな
Re: (スコア:0)
10年以上前に大学で暗号関連の講義を受けたときに、正規の方法での復号は解読とは言わない、と講師が言ってた記憶がある。
今ググってみたら、「暗号解読」は "cryptanalysis" の訳語として使われている？
Re: (スコア:0)
decryptっていう単語自体の意味には手段の正規／非正規はなく、
より明示的に非正規な方法で解読するという場合にcryptanalysisになるのでは
Re: (スコア:0)
暗号化⇔復号
じゃないの？
バックグラウンドで (スコア:0)
あの手の攻撃はCPUの状態を制御するために読み取りレートが下がりがちだし、
それなりの頻度で鍵を暗号化する鍵を変えていくと読み取り不可能なところまで持っていけるだろうか。
それとも、鍵を暗号化する処理自体がサイドチャネルになって細かく更新するのは逆に危険なのだろうか。
HSM内蔵 (スコア:0)
CPU+GPU+HSM+BOIS+Chip Setな感じ?（走召糸色木亥火暴）
"castigat ridendo mores" "Saxum volutum non obducitur musco"