2012-03-14 21 views
0

私は暗号化、特にインターネット接続を必要としない暗号化に関する質問があります(私設/公開鍵やOAuthメソッドとは対照的です)。ビットレベルでWindows Phoneリソースを暗号化しています...私はこれを正しくやっていますか?

問題はWP7アプリストアが安全でないことを発見したときに発生しました。私はリンクを投稿しませんが、基本的な検索では、市場で無料のWP7をダウンロードできるデスクトップアプリケーションが得られます。次に、.xapの名前を.zipに変更し、リフレクターを使用してコードを見てください。

私はDotfuscatorは私の問題を解決すると信じているが、学習経験として私は自分の解決策を考え出すことにしました。

私は事前に作成して、私は暗号化したいファイルを収集するプログラムを持ってすることを決定し、一つのファイルにそれらを置く、そのファイルを暗号化し、コンパイルのためのプロジェクトに追加します。電話アプリのコードでは、データの復号化のみが必要です。

私は/復号化を暗号化していたデータを復号化したときに、プレーンテキストとして読めることを意味し(〜10のWebサービスのための)いくつかのAPIキー、です。

これは私が思いついたこと(おおよそ、およびいくつかの変更を加えて)暗号化アルゴリズムである:私はこれを掲示足で自分自身を撮影することができる

public static byte[] SuffleData(byte[] data) 
{ 
    // Create a bit array to deal with the data on the bit level 
    BitArray bits = new BitArray(data); 

    // Generate a random GUID, and store it in a bit array as well 
    Guid guid = Guid.NewGuid(); 
    BitArray guidBits = new BitArray(guid.ToByteArray()); 

    int guidBitsIndex = 0; 

    // Iterate over all the data bit by bit 
    for (int i = 0; i < bits.Count/2; i++) 
    { 
     // if the current GUID bit is true (1), then swap 
     // the current bit with it's mirror 
     if (guidBits[guidBitsIndex]) 
     { 
      bool temp = bits[i]; 
      bits[i] = bits[bits.Length - i]; 
      bits[bits.Length - i] = temp; 
     } 

     // Because the data being shuffled is expected to 
     // contain more bits than the GUID, this index 
     // needs to be reset 
     if (guidBitsIndex == guidBits.Count) 
      guidBitsIndex = 0; 
     else 
      guidBitsIndex++; 
    } 

    // HideGuidInData hides the bits for the GUID in a hard 
    // coded location inside the data being encrypted. 
    HideGuidInData(ref bits, guidBits); 

    // Convert the shuffled data bits (now containing the 
    // GUID needed to decrypt the bits) into a byte array 
    byte[] shuffled = new byte[bits.Length/8]; 
    bits.CopyTo(shuffled, 0); 

    // return the data, now shuffled. (this array should 
    // be the length of the original data, plus 16 bytes, 
    // since 16 bytes are needed to store the GUID). 
    return shuffled; 
} 

が、それはデータことは知られていない場合このメソッドを使用して暗号化されています。ここで、nはファイル内のビットの合計数です。 (基本的には、GUIDをランダムに推測する確率よりはるかに高い)。

GUIDがファイル内に隠れていると仮定すると、ブルートフォース攻撃では時間がかかります。

私はこのソリューションに向かう途中で暗号化について学んでいましたが、私が読んだものはすべてこれよりも複雑なようでした(明らかに、私が読んだことは、それらの間に鍵が渡されます)。

私は何を学んだことはこれです:

  1. データを暗号化するための鍵にデータが格納されている場合、それは誰か、それを解読し、データ
  2. を取得するためには時間の問題だあり「完全に安全」というようなものはありません。暗号化にはさまざまなレベルの成功があります。一般的に言えば、暗号化の方法を選択するときは、安全性の高いデータの重要性を評価し、(プロセッサとメモリの制限を考慮して)データを暗号化プログラム。

私はこれは良い解決策であるには余りにも簡単であることを考えています。誰かがその疑いを証明し、なぜこれが他の暗号化方法ほど安全でないのかを私に説明できますか? (または私を非常に幸せにして、これはかなり安全だと教えてください?)

これらは私が今見ることができるこのアルゴリズムの欠点です:私は非常に暗号化していますので、アルゴリズムは、この程度TOO心配していない(メモリにあるように、すべてのデータを必要と

  1. 〜500バイトだ小さなファイル)
  2. アルゴリズムは、GUIDを(基本的にあなたがそれを解読するために最初から最後までのファイルをストリームすることはできません)を抽出するためにデータを読み込むストリームの位置を変更する必要があります。

私のアプリケーションは本当に重要ではありませんが、現実的に誰も悪意のある人が自分のコードを見るためにリフレクターを使用することはないでしょう(現実的には、害はない)。

+1

あなたが何かを暗号化する必要があると思えば、独自の暗号化アルゴリズムを考案しないでください。 WP7ではSystem.Security.Cryptographyは利用できませんか?そうであれば、そこから実際の暗号化アルゴリズムを使用してください。もしそうでなければ、暗号を提供するオープンソースライブラリを見てください。 http://www.bouncycastle.org/ – KristoferA

+0

あなたは、自分の暗号化アルゴリズムを発明することは、一般的に、悪い考えであり、すべての車輪を再発明していると100%正しいです。しかし、私は、プログラミングとwp7の両方の開発についての私の理解を豊かにするために遭遇する多くの問題について、楽しく、深くダイビングするためのアプリに取り組んでいます。その一環として私は、このアプローチを実践的なエクササイズではなく、学術的な理解を重視しました。 編集:はい、System.Security.Cryptographyのメソッドはうまくいきます。 –

+0

@PaulHazen暗号化アルゴリズムを発明することは、単に「ホイールを改革する」ことではありません。あなたがセキュリティ専門家でない限り、暗号化アルゴリズムを発明することは、安全ではない結果をもたらすことがほぼ保証されます*。 Eric Lippertは、本当に安全なシステムを設計する上での難しさの例を提供しています[ここ](http://blogs.msdn.com/b/ericlippert/archive/2011/09/27/keep-it-secret-keep-it- safe.aspx)。結論:専門家がセキュリティを設計できるようにします。 –

答えて

3

このアルゴリズムは非常にあなたを購入するつもりはありません。あなたのアプリをダウンロードしてリフレクターを使用することに苦労する人は、あなたの暗号化されたデータと解読プロセスのコードを持っています。彼らはあなたのデータを解読し、それを使用する方法を見つけることができます。

問題は、サイファー・テキスト内の「暗号化キー」を記憶していることです。攻撃者が使用されているアルゴリズムにもアクセスできる場合、そのセキュリティを確保する方法はありません。どの暗号システムを使用するかは関係ありません。

あなたが持っている基本的な問題は、携帯電話のアプリケーション自体がコードを見て、誰もがそれを見ることができますので、解読したデータを使用するために必要なすべての情報を有していなければならないことです。

それは、DVDなどのDRMスキームは日常こんなに早く壊れているのと同じ理由です。 DRMで保護された素材を再生できるすべてのデバイスまたはアプリケーションには、それを復号化する手段が必要です。デバイスやアプリケーションがコンテンツを再生している間にメモリを十分に掘り下げて復号鍵を見つけると、いつでも好きなときに保護されたメディアをクラックすることができます。

+0

このメソッドの中で最も弱い点は、データを復号化する難読化されたコードブロックが見つかったと仮定して正しいでしょうか?私は、これが「本当の」暗号化を扱うためにいくつかのサーバーコードを実装する以外にも可能な最善の策だと考えていました。 –

+0

はい。おそらく、サーバーに関わることで他にできることはあまりありません。より標準的な暗号化アルゴリズムを使用し、アセンブリのどこかに鍵を格納することができますが、基本的な問題は同じです。このようなスキームは、あなたのコードを簡単にブラウズしている人からあなたのAPIキーを隠すのに適していますが、ドットフリーズが同じことをするでしょう。誰かが実際にあなたのアプリケーションをリバースエンジニアリングしたいなら、ドットフローターが助けにならないでしょう。 –

+0

甘い、それはまさに私が聞きたかったものです!ありがとう! :)私の主な目標は、カジュアルなブラウザが自分のAPIキーを見ないようにすることでした。私は、これにより、少なくとも1つのレイヤーが追加されたと思います。 –

関連する問題