はじめに AWS Key Management Service （KMS） とは、データの暗号化に使用する暗号化キーを管理するためのマネージドサービスです。 KMS では、エンベロープ暗号化という暗号化方式を用いることでデータをセキュアに取り扱うことができます。 エンベロープ暗号化の Java での実装例について、日本語のドキュメントが少ないためまとめてみました。 エンベロープ暗号化とは ざっくり説明すると、 データ データを暗号化するための鍵（データキー） 鍵を暗号化するための鍵（マスターキー） を使い分けることでセキュアにしようよ、と言う仕組みのことを言います。 一般的な暗号化方式では、平文のデータを何らかの鍵を使って暗号化することで保護します。このとき、この鍵がデータとセットで盗まれてしまうと、暗号を解かれてしまい、生のデータを見られてしまいます。そこで、データを暗号化した鍵を、別の
TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized. Data delivered over an unencrypted channel is insecure, untrustworthy, and trivially intercepted. We owe it to our users to protect the security, privacy, and integrity of their data — all data must be encrypted while in flight and at rest. Historically, concerns over performance have been the
Pervasive Monitoring 去年のスノーデン事件を機にインターネット監視への危惧は高まりました。 「Pervasive Monitoring Is an Attack」(RFC7258)にて"大規模モニタリング"は攻撃であるとしたことは若者の間でも有名な話かと思います。 Opportunistic Encryption HTTPbisワーキンググループにおいても暗号化については多くの議論が行われました。 そして先日、「Opportunistic Encryption for HTTP URIs」というI-Dが公開されました。 （このI-DはHTTP/2のスペックから参照されていないので、HTTP/2の仕様策定をブロックすることはありません） このI-Dは、主目的を"大規模モニタリング"の影響を低減させることとしており、http uriで日和見暗号(サーバ認証を行わない暗号通信
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
