2016-11-03 3 views
2

セキュリティに関する具体的なニーズがあります。これは、私が快適である以上のセキュリティ関連コードを作成していることを意味します。私がやっていることがどこかの図書館で解決されたら、私に知らせてください。私はすぐに実装を中止します。私のセキュリティデザインは鳴っていますか?

Java(実際にはClojure)で書かれたサーバとJavaScript(実際にはClojureScript)で書かれたクライアントがElectronアプリケーションとして実行されています。これまでサーバーから情報にアクセスできるようにするために、様々なクライアントアプリケーションが必要です。暗号化を終了する必要があります。

エンドツーエンドの暗号化を実装するには、クライアントでプライベート公開鍵ペアを生成してから公開鍵と秘密鍵の暗号化バージョンをサーバーにアップロードする必要があります。次に、クライアントがランダムなデータに署名し、サーバーがそれを検証するような一種のチャレンジ応答を実行することによって、サーバーはユーザーを認証します。

登録プロセスは、次に、具体的には、楕円曲線のDiffie Hellman鍵ペアを生成する16バイトの塩を生成する、ことを生成した後https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use

に係る良い選択であると思わP-521(secp521r1)と含みます私はその塩を使ってパスワードを872791回pbkdf2、keylenを32、sha512を使用しています。ハッシュされたキーを使用して私は秘密鍵をaes-256-ctrで暗号化します。最後のステップは、塩の長さ、塩、および暗号化された秘密鍵を連結し、サーバーに送信することです。

私は、このすべてがTLSセキュリティで保護されたHTTPSを介して行われると仮定しています.HTTPSでは、サーバーの証明書の有効性が通常の方法でCAによって検証されます。将来、私はセキュリティを強化するために証明書のピン設定を使用するかもしれません。

これは健全なデザインですか?それは安全に見えますか?このうちのどれか、またはすべてが、私が維持管理している第三者のオープンソースライブラリに委任できただけですか?

私の実際のコード:

(def elliptic-curve-name "secp521r1")      ; https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use 
(def encryption-algorithm "aes-256-ctr")     ; http://lollyrock.com/articles/nodejs-encryption/ 
(def hash-bytes 32) 
(def salt-bytes 16) 
(def pbkdf-digest "sha512") 
(def iterations 872791) 

(defn encrypt-text [text key] 
    (let [salt (.randomBytes crypto salt-bytes) 
     salt-string (.toString salt "base64") 
     hashed-password (.pbkdf2Sync crypto key salt iterations hash-bytes pbkdf-digest) 
     text-cipher (.createCipher crypto encryption-algorithm hashed-password) 
     encrypted-text (gstring/format "%04d%s%s%s" 
             (count salt-string) 
             salt-string 
             (.update text-cipher text "utf8" "hex") 
             (.final text-cipher "hex"))] 
    encrypted-text)) 

(defn decrypt-text [encrypted-text key] 
    (let [salt-length (js/parseInt (subs encrypted-text 0 4) 10) 
     salt (.from js/Buffer (subs encrypted-text 4 (+ salt-length 4)) "base64") 
     hashed-key (.pbkdf2Sync crypto key salt iterations hash-bytes pbkdf-digest) 
     encrypted-text (subs encrypted-text (+ salt-length 4)) 
     text-decipher (.createDecipher crypto encryption-algorithm hashed-key)] 
    (str (.update text-decipher encrypted-text "hex" "utf8") 
     (.final text-decipher "utf8")))) 

(defn generate-key-pair [password] 
    (let [diff-hell (.createECDH crypto elliptic-curve-name) 
     public-key (.generateKeys diff-hell "base64") 
     private-key (.getPrivateKey diff-hell "base64") 
     encrypted-private-key (encrypt-text private-key password)] 
    [public-key private-key encrypted-private-key])) 
+1

私はこれは話題ではないと言っているわけではありませんが、あなたがここで不満足な答えを見つけたら、InformationSecurityはあなたに良い答えを与えるかもしれません。 –

+0

このマニュアルの暗号化を心配する理由は?強力な暗号でTLSを使用し、認証にクライアント証明書を使用するだけではどうですか? – mscdex

+1

彼はそれがサーバーに保存されている間、 "休憩中のデータ"のプライバシーについて尋ねています。 TLSは「転送中のデータ」を保護します –

答えて

2

これは素晴らしいスタートです。この種の質問は難しく、これらのことを安全に証明する方法はありません。その上のものthoughsを導くために、いくつかの良い概念「の柱は」あります

セキュリティの柱は:

  • プライバシー: このコードは、それを提供していません。中央の攻撃者はメッセージの構造を読み取ることができ、ほとんどすべてを理解することができます。これは彼らに強い立場を与えます。このシステムは、リプレイ攻撃に対応しています。

  • 認証 パスワードハッシュを照合することで、この人が実際にパスワードを知っていることを強く保証します。塩を含むPBKDF2は、最先端の技術であり、あなたがこれを持っているように見えます。

  • 整合性: このコードはそれを提供しません。公開鍵は飛行中に変更することができます。攻撃者は、自分の公開鍵を代用して、システムが読み込み可能なメッセージを生成させることができます。この攻撃は、公開鍵と秘密鍵を比較することによって、侵害を検出して対応するシステムの残りの部分に依存します。これは、一般に危険と見なされる「選択されたキー攻撃」を可能にすることによって、既知または未知の暗号攻撃にシステムを開く可能性があります。メッセージ全体の完全性を保証する必要があります。攻撃者は、自分が知っている秘密鍵と一緒に知っているパスワードと鍵を取って、切り替えます。リプレイ攻撃と組み合わされると、システムが破壊される可能性があります。

提案:メッセージ全体の構造が認証される必要があります

  • 。これには2つのアプローチがあります。キー付きMAC(Message Authentication Code)を使用するか、「Authenticated Encryption」アルゴリズムを使用してください。 MACは、より多くの一般的な暗号ライブラリに含まれています。あなた自身のMACを動かさず、これのためにハッシュを使用しようとしないでください。
  • メッセージのプライバシーを確​​保する必要があります。これは、メッセージがTLS経由で送信されていることを確認することで実現できます(既にこれを行っている可能性があります)。
  • メッセージには、リプレイ攻撃に対する保護が含まれている必要があります。これは多くの方法で行うことができます。 1つの強力な方法は、NONCE(Number of ONCe)を使用して、サーバーが各メッセージを一度しか受け入れないようにすることです。多くのリプレイ攻撃はクロスユーザであるため、これは「ユーザごと」であってはなりません。

あなたが絶対に正しく行っている部分は、プロセスの早い段階で公衆の精査を求めています。これにより、の方法が業界標準よりも優先されます。覚えておいてください

「誰よりも、最も無作為のアマチュアから最高の暗号技術者まで、誰でも自分が壊すことのできないアルゴリズムを作成できます」

https://www.schneier.com/blog/archives/2011/04/schneiers_law.html

EDIT:あなたは自分の秘密鍵を推測するからそれらを保護するパスワードは、あなたがそれらを認証するために使用するのと同じパスワードではありません(と彼らが同じパスワードを使用するための方法がないことを確認してください)

+0

ああ、はい、私はTLSの上でこれをやっていると言っていたことを忘れていました。私は中間者の攻撃を避けるためにCAを数えています。ある日、セキュリティを強化するために証明書の固定を行うかもしれませんが、私は小さな特異性がたくさんあることを知っています。 – Pablo

+0

潜在的に素朴な質問です。 TLSで正当であり、リプレイ攻撃を避けることはできませんか? – Pablo

+0

セキュリティ分析を行う際には、SSLを使用してこれを行うことができます。関係者のそれぞれが攻撃者になる可能性があるという観点から考える。1.人、2.ブラウザ、3. MITM、4.サーバー、5. DB。プロのパラノイアから狂って行こうとしないでください。 –

関連する問題