問題タブ [commoncrypto]

「SweetHMAC」と呼ばれる Swift 用の HMAC ダイジェストを使用するための単純なライブラリを作成しました。このライブラリはとてもシンプルで、基本的に Swift の CommonHMAC.h のラッパーです。

SweetHMAC を正しく使用して任意の iOS プロジェクトをビルドおよびデプロイできますが、セキュリティ上の問題があるようで、私のアプローチは安全ではありません。たとえば、iOS テストを実行した後に受け取る警告があります。

warning: linking against dylib not safe for use in application extensions

このコードは、iOS AppStore に入れるほど安全ではなく、アプリが拒否される可能性があります。OSXの場合は問題ありません。

Swift 用の HMAC ポートがあることは知っていますが、私の課題は、Swift が CommonCrypto を安全に使用できるようにすることです。

このアプローチを使用してこのプロジェクトを実装しましたが、正常に動作します!

私の質問は、iOS 用の Swift フレームワークで CommonCrypto のようなモジュールを安全に作成して使用することはどのように可能ですか?

アプリで以下の RFC アルゴリズムを使用しようとしています: https://www.rfc-editor.org/rfc/rfc5990

C# と Java の Bouncy Castle はそれをサポートしていますが、私は iOS で作業しています。私が知っているように、ios での暗号化に最適なツールはcommoncryptoライブラリです。問題は、このライブラリがそれをサポートしているかどうかです。

ドキュメントに関する有用な情報が見つかりません。ここの誰かが助けてくれることを願っています。

暗号化に ecc 手法を実装しようとしています。私は次の投稿を通過しました：

1. CommonCrypto を使用した楕円曲線 Diffie-Hellman に基づく共有シークレット

2. iOS の楕円曲線暗号

満足のいく解決策はありません。

今、私はpythonライブラリを使用することを考えています
https://github.com/yann2192/pyelliptic

しかし、objc で python ライブラリを使用する方法を見つける必要があるため、これが暗号化に ecc を使用するためのより良い解決策になるかどうかはわかりません。

誰かが私を正しい方向に向けることができますか?

サーバーから返されたphpでデータをデコードしようとしています:データAES 256がデコードされ、PKCS7パディングがあることは知っていますが、どのブロックモードを使用しているかわかりません

ここに私のphp関数があります：

およびエンコードされたデータの例

ECB (MCRYPT_MODE_ECB) でデコードすると、データの先頭のみがデコードされ、残りは読み取れません

CBC（MCRYPT_MODE_CBC）モードでデコードすると、読み取り不能になり始めます

結果は次のようになります(Objective-CでCommonCryptorを使用してMacで取得したもの):

誰かが何が間違っているか、正しい方法でデコードする方法を知っていますか?

Mac で一部のデータにデジタル署名してから、iOS で検証する必要があります。そこで、オープン ssl を使用して DER 形式の公開鍵の RSA キーペアと証明書を生成しました (SecKeyGeneratePair で生成を試みましたが、公開鍵を iOS にインポートするのは難しく、SecKeyRawVerify はまだ同じ結果で動作しません)、データに署名しました。マックアプリ。次に、iOS 検証でこのデータを検証すると、エラー コード -9809 で失敗しますが、Mac 検証で同じコードを実行すると成功します。

検証用のコードは次のとおりです。

Mac と iOS のデジタル署名検証に違いはありますか? Appleのドキュメントでそれについて何も見つけることができませんでした。

Crypto API 関数を使用する Windows プラットフォームで使用される暗号化コードがあり、これを OS X で Common Crypto を使用するように変換する必要があります。

基本的に元のコードは次のとおりですが、簡潔にするためにエラー チェックは削除されています。

私が理解している限り、これが起こっていることです： -

CryptAcquireContext - 暗号化を処理するオブジェクトを取得する

CryptCreateHash - MD5 ハッシュ オブジェクトを作成する

CryptHashData - MD5 で入力データをハッシュする

CryptDeriveKey、CryptDecrypt - キー m_hKey を使用して、RC4 で pData をデコードします。

pszInputData のサイズは 12 バイトで、MD5 ハッシュ オブジェクトの出力配列は両方のプラットフォームで同じです。

RC4 でデコードするために、Common Crypto で次のことを行っています。

Common Crypto からの出力 (outBuffer 配列) をオンライン RC4 デコーダーでテストすると一致するため、正しくデコードされています。

ただし、pData の Windows コードからの最終的な出力は、Common Crypto でデコードされた RC4 と一致しません。

ここで、Windows Crypto API 呼び出しに関して、不足している、または理解していない手順がいくつかあります。なぜ出力が異なるのですか？

(注意してください、RC4 を使用する際のセキュリティや欠陥についてのコメントは求めていません)

最初に MD5 で暗号化され、次に 3DES で暗号化されたログイン資格情報を送信する必要があるアプリがあります。

MD5 で文字列を暗号化するために CryptoSwift を使用することができました。ただし、Swift で 3DES によって暗号化するものは見つかりません。

CommonCrypto を試してみました。私が知る限り、これは C ですが、ブリッジ ヘッダーを使用して Objective C にインポートできます。

CommonCrypto を Swift にインポートする方法を、ブリッジ ヘッダー (フレームワークでは機能しないという警告付き) または Model.map のいずれかで説明する記事とチュートリアルをいくつか見つけました。ただし、どちらも機能していません。これが最新バージョンの iOS または Xcode の制限であるかどうかはわかりません。

誰かが代替案を教えてもらえますか?

ありがとう

編集済み

こんにちは、私が行った以下の手順をご覧ください

1. わかりましたので、newEncrypt という名前の新しいプロジェクトを作成しました。
2. 説明では、これは非フレームワーク アプリに限定されていると記載されているため、ヘッダー オプションを使用しないことにしました。
3. newEncrypt 内に CommonCrypto というフォルダーを作成し、その中に module.map ファイルを入れました。その内容は次のとおりです: module CommonCrypto [system] { header "/usr/include/CommonCrypto/CommonCrypto.h" export * }
4. ${SRCROOT}/CommonCrypto を迅速なコンパイラ検索パス インポート パスに追加しました。デバッグしてリリースします。
5. これは、指示が停止する場所です。クラスに CommonCrypto をインポートする必要があると思います。このエラーは、「目的の C モジュール 'CommonCrypto' をビルドできませんでした。また、「/usr/include/CommonCrypto/CommonCrypto.h」または「/newEncrypt/CommonCrypto/CommonCrypto.h」に CommonCrypto ライブラリ ファイル (CommonCryto の「include」フォルダーから) が必要だと思いますか?私はこれを試しましたが、同じエラーが発生します。
6. 次に、#import を使用してヘッダー ファイルを追加しようとし、-lfoo を他のリンカ フラグ debug および release に追加しました (ただし、これは正しいものではない可能性があります)。これがまだ必要な場合に備えて。しかし、私はまだ同じように客観的なcエラーを構築できませんでした。私は何か間違ったことをしていると確信しています

ECB モード (おもちゃの暗号化) と PKCS7 パディングを使用して AES128 で暗号化された暗号文を使用すると、次のコード ブロックにより、iOS 8 で完全な平文が復元されます。

iOS 7 で同じコード ブロックを実行すると、正しいプレーンテキストが生成されますが、切り捨てられます。どうしてこれなの？

以下に自己完結型のテスト ハーネスと結果を追加しました。

テスト ハーネス:

iOS 8 の結果:

iOS 7 の結果:

およびその後の結果:

更新：これをなぞってください：私が変わるとき

kCCOptionPKCS7パディング | kCCOptionECBMode ⇒ kCCOptionECBMode

iOS 7 での結果は期待どおりです。どうしてこれなの？？暗号文に PKCS7 パディングが埋め込まれているため、バイト数がブロック アラインされていることはわかっていますが、これは理にかなっていますkCCOptionPKCS7Padding | kCCOptionECBModeが、iOS 7 でのみ設定によって切り捨てられた動作が発生するのはなぜですか?

編集:上記のテスト暗号文は、この Web サイトの両方から生成され、次の関数で手動 PKCS7 パディングを使用して PHP の mcrypt を個別に使用して生成されました。

外：

I9JIk5BskZMZKJFB/EAs+N2AYzkVR15DoBbUL7cBydBkGlujVnzRHvBNvSVbcKh

更新:適切に PKCS#7 でパディングされた暗号文は次のようになります。

I9JIk5BskZMZKJFB/EAs+N2AYzkVR15DoBbUL7cBydA6aE5a3JrRst9Gn3sb3heC

これがそうでなかった理由です。

sqlcipher ライブラリの最新バージョンを iOS プロジェクトにインストールしました。そこで、OpenSSL から CommonCrypto に切り替えます (sqlcipher iOS チュートリアルも変更されました)。

さて、「DB エラー: 26 "ファイルが暗号化されているか、データベースではありません" が表示されます。CommonCrypto を使用する新しい暗号化エンジンは、以前に OpenSSL で暗号化され、2 つのケースで SQLCipher を使用した私の db ファイルを認識しないようです。もちろん、 dbキーは同じです...

論理的ですか？OpenSSL を維持する必要がありますか?