問題タブ [commoncrypto]

セキュリティ フレームワークを使用して、mac/ios でopenssl を使用せずに PKCS12 (.p12) blob を生成する機会はありますか?

X509、CA、および RSA キーを自分で組み合わせる必要がありますか、それともフレームワークはより高いレベルの API をサポートしていますか?

これを行う方法が本当に見つかりませんでした。

ありがとう

NSData+AES256 クラス内に次のコードがあります。次のコードを使用して、NSString に AES CBC 暗号化を試みています。私は鍵とivを持っています。しかし、結果としてnullになります。何が問題なのかを見つけることができません。これは私が試したものです-

opensslはosx10.7+で非推奨になっているため、opensslから内部osxキーチェーンと暗号化機能に切り替えたいと思います。

しかし今、私は非対称暗号化/復号化に固執しています。

ランダムに生成された対称鍵を非対称（RSA）鍵で暗号化/復号化するにはどうすればよいですか？opensslを使用すると、非常に簡単です。

Apple dev docsで、彼らはCommonCryptoが非対称暗号化をサポートしていると言っていますが、ヘッダーをチェックしている間、私は対称的なもののサポートしか見ることができません。

ヒントはありますか？

OpenSSLと緊密に結合されている既存のアプリケーションでは、OSXネイティブ暗号化ライブラリを利用したいと思います。これに関連して、私は次の質問があります：

1. OpenSSLは2つの仕事をしていると思います。1つはトランスポート層を安全にし、もう1つはデータの送受信を処理します。いくつかのブログとドキュメントを読んでいるうちに、CommonCryptoとNSStreamを使用する必要があるという結論に達しました。ここで、CommonCryptoは暗号化と復号化に使用され、NSStreamはデータの送受信に使用されます。それが間違っているように聞こえたら、私を訂正してください。

2. NSStreamの使用は非ブロッキングフレームワークのようですが、既存のアプリケーションはブロッキングメカニズムの恩恵を受けます。これを回避する方法はありますか？

iOS で AES/CFB8 ストリーミング暗号を実装しようとしています。これを実現する方法は、Apple が提供する CommonCrypto ライブラリを使用することだと思います。

私が見つけた小さなドキュメントはすべてブロック暗号しか示していません。では、ライブラリを使用して AES/CFB8 ストリーム暗号を実現するにはどうすればよいでしょうか?

この記事に従って、パスワード暗号化機能をアプリに書き込もうとしています。

関数を実行し、CCCalibratePBKDFラウンド数を出力する関数を作成しました。

これは完全に機能しますが、次の部分を実装しようとすると、すべてがうまくいきません。

関数呼び出しの記述を開始するCCKeyDerivationPBKDFと、関数とすべてのパラメーターが自動的に完了します。入力を進めると、すべてのパラメーターも自動入力されます。

しかし、私がヒットするとすぐに; 「「CCKeyDerivationPBKDF」の呼び出しに一致する関数がありません」というエラーをマークし、ビルドなどを行いません。

CommonCrypto/CommonKeyDerivation.hとCommonCrypto/CommonCryptor.hをインポートしました。これらは両方とも、列挙型の名前に必要だったためです。

Mac OS X10.7でソースファイルの1つをコンパイルし、これらの非推奨の警告を受け取ります。

からMD5関数を使用していopenssl/md5.hて、次のようなOpenSSL呼び出しのCommonCryptoバージョンに切り替えることができたOpenSSL非推奨警告の別のセットがありました。

EVP_*しかし、これらの呼び出しに関連するOpenSSLの互換性については何もわかりません。EVP_*これらのOpenSSL呼び出しに対してOSX10.7で「無料」の互換性サポートを取得するために私ができる同様のことはありますか？

実行時に、私のiOSアプリケーションは、他の誰かのJavaによって生成されたパブリックプライベートRSAキーペアを含むファイルを受け取ります。

この方法を使用して、公開鍵を正常に読み取り、使用しました。この方法では、鍵から一部のプリアンブルが削除されます。

秘密鍵を使いたいのですが。同じ方法ではうまくいきません。前文がどういうわけか違うと思いました。ブログでは、PKCS＃1 PEMキーをインポートしていると示唆されていましたが、バイナリであると記載されているため、Base64でエンコードされたDERキーを意味していると思います。また、私が持っているキーは、代わりにPKCS＃8でエンコードされている可能性があることもわかりました。

確かに使える

サンプルの秘密鍵とopensslは文句を言いません。

公開鍵がPKCS＃1と秘密鍵がPKCS＃8であったことは理にかなっていますか？

ただし、可能であれば、OpenSSLに対してリンクするのではなく、CommonCryptoとSecurityFrameworkを使用したいと思います。Mac OSでは、libsecurityにPKCS＃8を読み取る関数がありますが、これはまだiOSに到達していません。正直なところ、ソースを読んでみましたが、実際にどこでキーが削除されているのかわかりません。

[TL; DR] DER秘密鍵からバージョンとアルゴリズムのPKCS＃8フィールドを削除し、CommonCryptoまたはC / C ++ / ObjCを使用してプレーンキーを取得するにはどうすればよいですか？

暗号化にCTRモードでAES128暗号を使用し、さまざまなクライアント（Android/JavaおよびiOS/ObjC）に実装しています。パケットの暗号化に使用される16バイトのIVは、次のようにフォーマットされます。

パケットカウンタ（送信されたパケットに含まれる）は、送信されるパケットごとに1つずつ増加します。最後のバイトはブロックカウンターとして使用されるため、256ブロック未満のパケットは常に一意のカウンター値を取得します。CTRモードでは、ブロックごとにカウンターを1ずつ増やし、最後の8バイトをビッグエンディアンの方法でカウンターとして使用するように指定されているか、少なくともこれがデファクトスタンダードであると想定していました。これは、Sun暗号化の実装にも当てはまるようです。

対応するiOS実装（CommonCryptor、iOS 5.1を使用）がパケットをデコードするときの最初のブロックを除いてすべてのブロックをデコードできなかったとき、私は少し驚いた。CommonCryptorは他の方法でカウンターを定義しているようです。CommonCryptorは、ビッグエンディアンモードとリトルエンディアンモードの両方で作成できますが、CommonCryptorコードのあいまいなコメントは、これが完全にはサポートされていない（または少なくともサポートされていない）ことを示しています。

ブロックごとにデコードすることにより、上記のようにIVを設定するたびに、うまく機能します。

私の質問：一度に複数のブロックをデコードするときにCTR / IVモードを実装する「正しい」方法はありますか、それとも異なる暗号ライブラリを使用するときに相互運用性の問題になると予想できますか？CommonCryptoはこの点でバグがありますか、それともCTRモードを別の方法で実装するだけの問題ですか？

以下は、基本クラスとしてiOS5で問題なく動作しましたが、iOS6では失敗します（SIGABRT）。それはOSのものなのか、それともアーキテクチャーなものなのか？

また、付随するMD5ハッシュが機能することにも注意してください。

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