2

ユーザーがデバイスにデータを保存できるアプリケーションを作成しています。データベースストレージの使用を考えていました。しかし、デバイスにローカルに保存されているデータを操作できることをどこかで読んでいます。では、データに対するそのような「攻撃」を回避する最善の方法は何でしょうか? データベース内の各フィールドを暗号化することを考えていましたが、デバイスにも暗号化キーを保存する必要があります (?)。それで、誰かが私の考えの他のアイデア/改善を持っていますか?

助けてくれてありがとう！

4

2 に答える 2

4

私はそれを大きな挑戦にする方法を探しています

勝負を受けて立つ ：）

最初にすべきことは、データをアプリ ディレクトリに保存することです。これは、通常のデバイスではユーザーや他のアプリが読み取ることができないためです。Contextアプリ データへのリンクは、たとえばから取得できますContext.html#getDir()。取得するディレクトリEnvironmentは公開されています。

これにより、平均的なユーザーがデータを取得できなくなります。しかし、多くの人がルート化されたデバイスを持っていて、問題なくデータにアクセスできるため、まだかなり安全ではありません.

もっと難しくするには、暗号化が必要です。WEP のように根本的に破られていない強力な暗号化であれば、問題ありません。暗号化を使用すると、暗号化されたデータは妥当な時間内に復号化できないため、ユーザーにキー (および暗号化方法) を見つけるように強制します。

これにより、ユーザーではなくアプリで使用できる秘密鍵がどこかにあるという問題が発生します。そして、これを行うための安全な方法がないため、これは創造性を発揮する必要がある部分です.

最も簡単な方法は、キーをアプリ コードに平文で配置することです。のようにprivate static final String SECRET = "42"。ファイルを暗号化するだけで、データを読み取るためのプログラミング スキルが必要になるため、ほとんどのユーザーはそれ以上掘り下げることができなくなります。

ユーザーがこれらのスキルを持っている場合、アプリのコードを調べ始める可能性があります (たとえば、dex2jar + jd-guiを使用)。アプリのリバース エンジニアリングがどれほど難しいかを知りたい場合は、同じことを行う必要があります。

アプリの内部クラス名、メソッド名、変数名がコードのように短縮されるため、proguard を使用してコードを難読化すると、コードの理解/暗号化メソッド + パスワードの検索が難しくなりA.B.c(d)ます。ただし、デバイスでメソッドの名前を変更する必要があるため、Android の API へのメソッド呼び出しの名前を変更することはできません。のような文字列定数"42"も変更されません。

それを難し​​くするための次のステップは、その定数をコードによって動的に生成されるものに置き換えることです。たとえば、以下の基本的な例では、数字を 2 で割ってパスワードを作成します。このアプローチを使用する場合の利点は、パスワードがプレーンテキストで保存されなくなり、データをパスワードに変換する方法を理解/リバース エンジニアリングする必要があることです。

private static final byte[] password = {8, 4};
private String getPassword(byte[] data) {
    StringBuilder sb = new StringBuilder();
    for (byte b : data) {
        sb.append(String.valueof(b / 2));
    }
    return sb.toString();
}
// returns "42" if I did not make a mistake

次の脆弱な点は、デバイスの暗号化 API の呼び出しが (名前を変更できないため) 簡単に見つけられることです。これにより、暗号化を探す場所を見つけやすくなります。ここでのわずかなエラーがデータを破損したり、完全な暗号化を破ったりする可能性があるため、独自の暗号化メソッドを作成したくない場合は、作成しないことを強くお勧めします。

たとえば、リフレクションを使用すると、この問題を強化できます（メソッドの名前を指定してメソッドを呼び出す/で提供されるクラスString）。上記の例がパスワードで行ったように、難読化することStringもできます。

これらすべてを行い、この方法ほど単純ではない方法を使用しないと、非常に難しくなる可能性があります。たとえばdexguardはそれを行うことができますが、無料ではなく、多くのアプリで同じ方法が使用されており、カスタム方法よりも多くの人がそれを破ろうとするという問題があります.

キーの生成に使用されるアプリ内の情報を非表示にする適切な方法と、キーの生成と暗号化/復号化を非表示にする方法を見つけることは、自分で考え出すのが最善であるため、その方法自体は公開されていません。

情報の一部をネイティブ コードに移動するなど、多くの手法を組み合わせて情報を非表示にすることができるため、私のような Java の専門家は苦労したり、ネットワーク接続を使用してサーバーに何らかの作業をさせたりすることができます。

しかし、結局のところ、それはすべてあいまいさによるセキュリティであり、すべての追加のセキュリティ対策はユーザーに利益をもたらすものではなく、余分な処理時間と追加のアプリ サイズを必要とします。

于 2012-09-01T12:40:16.160 に答える
2

では、データに対するそのような「攻撃」を回避する最善の方法は何でしょうか?

装置の上に置かないでください。

アプリのユーザーに対してデータを保護したい。

その後、デバイスの上に置かないでください。これはユーザーのデバイスであり、ユーザーの帯域幅であるため、ユーザーのデータです。

しかし、ユーザーがそうしようとすることがわかった場合、それを大きな挑戦にする方法を探しています。

内部ストレージでデータベースなどを使用するだけで、99% の Android デバイス ユーザーがデータにアクセスできなくなります。残りの 1% を止めるためにできることは何もありません。

于 2012-09-01T12:32:10.493 に答える