RHEL, OpenShiftのFIPS準拠モード
はじめに 本記事では、Red Hat製品、特にRHELとOpenShiftをFIPS準拠モードで使用するためにはどうするか、どのような仕組みによってFIPS準拠モードで稼働するか、について調べた内容を書きました。 KubernetesをFIPS準拠させるのはなかなか大変で、実際Red Hatも「OpenShiftはFIPSに対応していたつもりが実はできてませんでしたすみません」というCVEを発行したりしています (CVEの技術的背景等はこちらに解説があります)。 なお、本ドキュメントでは便宜上、FIPSの承認ステータスがFIPS validatedなものもModules in Progressなものもまとめて「RHEL(もしくはOpenShift)はFIPS準拠している」「FIPS準拠した暗号化モジュールを使って」のような表現をしていますのでご注意ください。正確にはざっくりRHEL 8系は
特別勉強会：国際的な動きと私たちのセキュリティ技術/PKIのこれまでとこれから - 松本泰氏をお招きして - 開催のお知らせ - JPNIC
2024年3月1日 各位 一般社団法人日本ネットワークインフォメーションセンター 特別勉強会： 国際的な動きと私たちのセキュリティ技術/PKIのこれまでとこれから - 松本泰氏をお招きして - 開催のお知らせ 本イベントは既に終了しました。 公開鍵基盤の技術であるPKIをはじめとする国内で展開されるセキュリティ技術に関し、 IETFといった標準化団体やPKIに関わる業界団体等で、 相互運用性、国際化、認証業務における透明性、近年ではIoT等のセキュリティに関する活動など、 組織を超えた幅広い議論と取り組みが行われてきました。 この度、JNSA PKI相互運用技術WGをはじめとしてInternet Week等でも活躍され、 長年にわたりPKI技術について貢献されている松本泰氏を中心に、 さまざまな分野で活躍されている方々をお招きし、 「PKIのこれまでとこれから」の講演とそれを受けた議論を行
トラストのためのデジタル署名検証解説|JNSA電子署名ワーキンググループ
目的 さまざまなサービスがデジタル化し、ネットワークを介して提供され、デジタルデータが国境を越えて飛び交う中で、何をどうやって信用するかは重要な課題です。中でもデータについては、流通するデータ量が膨大になるにつれ、１つ１つを確認することは容易ではなく信頼できる根拠が必要となり、それは「電子署名」の役割と言えます。 さまざまな電子署名方式について紹介し、標準化の進んでいるデジタル署名について、単なる検証処理だけでは確認できないトラストの要素について解説します。デジタル署名技術の専門家ではない利用者向けの導入から、最新の技術動向まで幅広く記載していますので、トラストを確保したい場合の参考としていただければと思います。 なお、合わせて2021年4月に公開した「デジタル署名検証ガイドライン」についても若干の誤記修正や情報の更新を行いましたので、v1.1として更新しています。 「デジタル署名検証ガイ
認証に電話網を使うのはそろそろやめよう
こんにちは、Azure Identity サポート チームの 高田 です。 本記事は、2020 年 11 月 10 日に米国の Microsoft Entra (Azure AD) Blog で公開された It’s Time to Hang Up on Phone Transports for Authentication の抄訳です。新着記事ではありませんが、以前より繰り返し様々な記事で参照されており、多くのお客様にとって有用であるため抄訳しました。ご不明点等ございましたらサポート チームまでお問い合わせください。 以前のブログ パスワードで攻撃は防げない - Your Pa$$word doesn’t matter では、パスワードに潜む脆弱性を明らかにしました。加えて、「でもパスワード以外の他の認証方法も侵害される可能性あるでしょ」という無数の DM や E メールに対する答えとして
ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
秘密鍵のファイル周りの話
開発していると、公開鍵暗号の技術を利用する場面は多々ある。 EC2インスタンスへのSSHする時や、Snowflakeの認証時に RSA キーペアの秘密鍵を利用する 公開鍵証明書 ... いろんな用語、トピックがあり混乱するのでまとめてみた。 ここではとりあえず特にRSA暗号を念頭に置き話を進める。 規格群 そもそも公開鍵暗号に関する技術はいろいろな形で規格が定められていたり、標準化されていたりする。 PKCS Public-Key Cryptography Standards の略で、RSAセキュリティというソフトウェア会社が考案した公開鍵暗号の規格群のこと。元々はRSAセキュリティ社が自社の暗号技術に関する特許を利用促進するために発行したのがはじまり。 近年ではその一部は IETF などと標準化が進められており、 RFC として整備されているものも多い。 内容ごとに PKCS #1 など
IPAサイトの改変に袖を涙で濡らすPKIエンジニアが作った昔を懐かしむリンク集(仮)
2023年3月31に情報処理推進機構(IPA)のウェブサイトの大幅変更があり、過去に使えていたコンテンツが参照できなくなったり騒ぎになりました。かくいうPKIエンジニアをしている私も結構困ったので、PKIエンジニアがよく参照しそうなコンテンツがそのままなのか、移動したのか、廃止になってアーカイブされたのかなど調べて自分向けの「リンク集」を作っておきました。 よかったら使ってください。 [移動] TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編）(最終更新 2021.12月) https://www.ipa.go.jp/security/crypto/guideline/ssl_crypt_config.html (移動先) https://www.ipa.go.jp/security/crypto/ssl_crypt_config.html (旧リンク切れ) [移動]
HPKE とは何か | blog.jxck.io
Intro HPKE (Hybrid Public Key Encryption) が RFC 9180 として公開された。 RFC 9180: Hybrid Public Key Encryption https://www.rfc-editor.org/rfc/rfc9180.html HPKE は、公開鍵暗号方式と共通鍵暗号方式を組み合わせて(ハイブリッド)任意の平文を暗号化するための、汎用的な枠組みとして標準化されている。 この仕様は、多くのユースケースが想定されており、 RFC になる前から ECH (Encrypted Client Hello), MLS (Message Layer Security), OHTTP (Oblivious HTTP) など、さまざまな仕様から採用を検討されている。 本サイトで書く予定の他の記事でも HPKE は頻出する予定であり、今後より多く
sigstoreによるコンテナイメージやソフトウェアの署名 - knqyf263's blog
恐ろしく長い上に割と複雑なので最後まで読む人はほとんどいないと思うのですが、将来確実に忘れてしまう自分のために書いたので別に悲しくありません。 まえがき 背景 sigstoreの概要 sigstoreを構成するツール群 Cosign Rekor Fulcio 署名方法 コンテナイメージ 鍵ペアの生成 署名 検証 Blobs 鍵ペアの生成 署名 検証 署名の仕組み コンテナイメージ OCI Registryについて 署名の保存先 署名フォーマット 署名検証 検証が不十分な例 Blobs 参考 まとめ まえがき 鍵の管理不要でソフトウェア署名を可能にするKeyless Signingについて解説を書こうと思い、まず前提知識を書いていたら信じられないぐらい長くなったので前提知識だけで1つの記事になりました。 後述するsigstoreは急速に開発が進んでいるプロジェクトであり、ここで書いている記述
CVE-2022-21449: Psychic Signatures in Java
The long-running BBC sci-fi show Doctor Who has a recurring plot device where the Doctor manages to get out of trouble by showing an identity card which is actually completely blank. Of course, this being Doctor Who, the card is really made out of a special “psychic paper“, which causes the person looking at it to see whatever the Doctor wants them to see: a security pass, a warrant, or whatever.
What are ssh-keygen best practices?
Most users would simply type ssh-keygen and accept what they're given by default. But what are the best practices for generating ssh keys with ssh-keygen? For example: Use -o for the OpenSSH key format rather than the older PEM format (OpenSSH 6.5 introduced this feature years ago on 2014-01-30) How should one calculate how many rounds of KDF to use with -a? Should -T be used to test the candidate
SSH Key Best Practices
Ensure Separation Ensure SSH Keys Are Associated With a Single Services Tie SSH keys back to an individual services, rather than just a generic key that is associated with multiple services github / acquia /aws etc . This will provide an effective SSH audit trail and more direct oversight. Use a separate key per client you SSH from So don’t copy the private key from your laptop to another laptop f
Bluetooth通信実装のセキュリティ観点を4ステップ + 1で理解する - Flatt Security Blog
Bluetoothは、米国Bluetooth SIG,Inc.の商標です。 イントロ BLE通信 概観 GATTプロファイル ペアリング 脆弱性 1: Characteristicの権限指定ミスによる平文通信 観点: GATT Characteristicと属性 対策: characteristicへの暗号化必須属性の付与 脆弱性 2. Legacy Pairingにおける暗号化された通信のブルートフォース LE Legacy Pairingにおける鍵生成と鍵交換 TKの生成 random値の生成 STK/LTKの生成 観点: ペアリングフローの盗聴による経路復号 既成ツールを用いたTKの総当りと通信の復号実践 対策: Legacy vs Secure Connection 脆弱性 3. Secure ConnectionのJust Worksにおけるperipheralのspoofing
セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ
徹底解剖 TLS 1.3 | 翔泳社
wolfSSLをもとに、SSL/TLSの正しい利用法と仕組みを理解する 暗号化された安全な通信は、ネットワークを使う全てのアプリケーションにとって、 考慮すべき重要な課題です。 セキュアな通信を実現するために用いられる技術SSL/TLSの最新版がTLS 1.3であり 各種SSLライブラリも対応してきています。 ただ、ライブラリだけが最新のものになっても、仕組みを知り、 正しく使わなければ、安全は担保されません。 そこで本書は、そんなTLS 1.3の基礎的なプロトコルの流れから、 暗号化・認証の仕組み、アプリケーション実装のベストプラクティスを 組み込みシステム向けの軽量＆高機能なライブラリwolfSSLを例に 解説していきます。 さらに、ライブラリコードの解説を含め、内部実装にまで踏み込んだ解説も行い、 SSLライブラリを徹底的に理解できる一冊です。 Part 1：TLSの技術 ・Chap
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Google Chrome」にCookieの盗難を防ぐ技術「DBSC」が導入へ／公開鍵暗号技術やTPMを活用して、セッション盗難の被害を最小限に
RFC 9500: Standard Public Key Cryptography (PKC) Test Keys
A Deep Dive into TPM-based BitLocker Drive Encryption – Sec Team Blog
Database Cryptography Fur the Rest of Us - Dhole Moments
SSH Key Management Overview & 10 Best Practices | BeyondTrust