2

更新:この質問は、コンテンツのクライアント側を保護 (暗号化/難読化) することと、サーバーから送信する前に保護することに関するものです。itune のようなアプローチでは、転送前にファイルが暗号化/難読化されていないため、長所と短所は何ですか。

元の質問のメモに追加したように、遵守する必要がある契約があります (drm を実装するほとんどのサービスの場合と同様)。私たちは DRM フリーを推進しており、ほとんどのコンテンツ プロバイダーとの契約はそれに基づいていますが、だからと言って既に課せられている義務から解放されるわけではありません。


私は最近、itunes / fairplay が drm にどのようにアプローチするかに関する情報をいくつか読みましたが、サーバーが実際に保護なしでファイルを提供することを期待していませんでした。

この回答の引用は、問題の精神を捉えているようです。

目標は、単に「正直な人を正直に保つ」ことであるべきです。これより先に進むと、次の 2 つのことだけが起こります。

  1. 私たちは勝てない戦いをしています。カンニングしたい人は成功します。
  2. 私たちは製品を使いにくくすることで、製品の正直なユーザーを傷つけています。

ここでは正直なユーザーへの影響は見られません。これがクライアント側で発生するかサーバー側で発生するかに関係なく、ファイルはユーザーに関連付けられます。これにより、1 のユーザーに別のチャンスが与えられます。

追加情報: クライアント環境は adobe air で、複数のコンテンツ タイプ (音楽、ビデオ、フラッシュ アプリ、画像) が含まれます。

では、iTunes の Fairplay のようにして、メディア クライアント側を保護することは合理的でしょうか。

注:アンブレイカブル DRM は解決不可能な問題だと思います。これに対する答えを探しているほとんどの人は、その必要性は、コンテンツ プロバイダーとの契約に既に関係していることに関係しています。

4

7 に答える 7

6

ここでのキッカーは、契約に「合理的な最善の努力」と書かれていることであり、法廷でそれが何を意味するのか、私にはまったくわかりません.

あなたがしたいことは、あなたが設定した DRM でクライアントを満足させることです。あなたのクライアントが DRM について何を考えているか、できること、リソースのコスト、または DRM が本当に煩わしいことをクライアントが実際に認識しているかどうかはわかりません。あなたはそれに答えなければならないでしょう。クライアントを教育しようとすることはできますが、それは標準以下の仕事を説明しようとしていると見なされる可能性があります.

クライアントが満足していない場合、次のフォールバックの立場は訴訟なしで支払いを受けることであり、そのためには契約が合理的に明確である必要があります. 残念ながら、「合理的な最善の努力」は明確ではないため、法廷に持ち込まれる可能性があります。クライアントの都合で契約の一部を再交渉できる場合もあれば、そうでない場合もあります。

他のすべてが失敗した場合は、訴訟に勝つことを望みます。

私は弁護士ではありません。これは法的助言ではありません。これは、技術的な問題というよりも、期待と可能な法的解釈の問題であると私は考えています。ここであなたを助けることはできないと思います。こういう専門の弁護士に相談したほうがいいのですが、どの専門をすすめたらいいのかもわかりません。米国にいる場合は、地元の弁護士会に電話して紹介を依頼してください。

于 2009-12-01T14:41:27.843 に答える
4

データをコピーできます スタンドアロンのクライアントハードウェアが「良い」コピーと「悪い」コピーを区別できない限り、すべての一般的なコピーとコピーメカニズムを制限することになります。ほとんどのDRM企業は、このテクノロジーが私をどれだけ自由にするかを教えてくれることで、この事実に対処しています。同じことを何度も聞くと、まるで人々が信じ始めるかのように...

クライアントでコードを保護することはできません。サーバー上のコードを保護することは、大部分が解決された問題です。クライアントのコードを保護することはできません。現在のすべてのアプローチには、けちな制限があります。

Impactは微妙な方法で機能します。少なくとも、クライアント側のDRMを実装するための追加コスト(および「DMCA」を叫ぶ弁護士ゴリラの大群を含むすべてのフォローアップコスト)があります。このコストを収益の増加。


それはコードと暗号だけではありません。クライアント側のDRMを実装すると、マーケティング、広報、法務の一連のイベントを解き放ちます。彼らがユーザーを遠ざけるために立ち止まらない限り、あなたはわざわざする必要はありません。

于 2009-11-30T23:15:27.257 に答える
3

「それは合理的ですか」という質問に答えるには、保護しようとしているものを「保護する」という言葉を使用するときに明確にする必要があります...

たとえば、次のことをしようとしていますか?

  1. 許可されたユーザーは、特定の状況 (例: レンタル期間の満了、別のコンピューターへのコピーなど) でアプリを介してダウンロードしたコンテンツを使用できませんか?
  2. 許可されたユーザーは、特定の状況下 (例: レンタル期間の満了、別のコンピューターへのコピーなど) でダウンロードしたコンテンツをアプリ経由で使用できませんか?
  3. アプリを介して許可されたユーザーから受け取ったコンテンツを許可されていないユーザーが使用することはありませんか?
  4. 許可されていないユーザーが、アプリを介して許可されたユーザーから受け取ったコンテンツを使用することはできませんか?
  5. 既知のユーザーが、アプリを介してサーバー上のメディア ライブラリから未購入/未承認のコンテンツにアクセスできないようにしますか?
  6. 既知のユーザーが、アプリを介してサーバー上のメディア ライブラリから未購入/未承認のコンテンツにアクセスできないようにしますか?
  7. 不明なユーザーが、アプリ経由でサーバー上のメディア ライブラリにアクセスできないようにしますか?
  8. 不明なユーザーがアプリ経由でサーバー上のメディア ライブラリにアクセスできないようにしますか?

等...

上記の「任意のアプリ」には、次のようなものを含めることができます。

  • サイトと相互運用/協力するように設計された他のプレーヤー プログラム (例: flickr 用)
  • コンテンツを他の形式 (場合によっては非 DRM 形式) に変換するように設計されたプログラム
  • するために設計された敵対的なプログラム

リンクした記事から、DRM クライアント側を適用する際に考えられる制限のいくつかを確認し始めることができます...

  • 3 つ目は、iTunes Store の Linux クライアントである PyMusique で最初に使用されたもので、iTunes のふりをしています。Apple のサーバーから曲をリクエストし、購入した曲をiTunes のようにロックせずにダウンロードしました。

  • FairKeys で使用されている 4 番目のものも、iTunes のふりをしています。Apple のサーバーからユーザーのキーを要求し、これらのキーを使用して既存の購入済み曲のロックを解除します。

これらのアプローチはどちらも、適用されている DRM を破ったり、関連する製品をハッキングしたりする必要はありませんでした。関連するプロトコルを受動的に観察し、それを模倣するだけで簡単に実行できます。

したがって、問題は次のようになります。これらの種類の攻撃から保護しようとしていますか?

  • はいの場合、クライアントが適用する DRM は合理的ではありません
  • 「いいえ」の場合 (たとえば、Apple/iTunes のように、自分のアプリを使用している人だけに関心がある場合)、そうかもしれません。

(考えられるすべての状況について、このプロセスを繰り返します。回答が常に「クライアント適用の DRM で保護される」または「この状況から保護しようとしていない」の場合、クライアント適用の DRM を使用することは理にかなっています。 .)


私の最後の 4 つの例では、DRM は副作用としてこれらの状況から保護しますが、それらの制限を強制するのに最適な場所ではないことに注意してください。これらの種類の制限は、ログイン/承認プロセスでサーバーに適用するのが最適です。

于 2009-12-10T03:41:50.747 に答える
0

バイパスは通常、入力/出力を 1 つの暗号化 API 呼び出しに変更するだけなので、暗号化だけでは、通常、コンテンツの使用が許可されているかどうかを示すブール値を送信するのと同じくらい優れています...

保護を文字通り 5 分以上保持する場合は、クライアント側で強力なバイナリ難読化を使用する必要があります。クライアント側で復号化を使用して、データを再生できないようにし、システムをバイパスする唯一の方法は、バイナリ保護スキーム全体をリバース エンジニアリングすることです。適切に行うと、これによりすべての子供が停止します。

別の注意として、これがオペレーティング システムで実行される製品である場合は、Windows PEB/TEB/syscalls やプロセッサのバグなど、プロセッサ固有またはオペレーティング システム固有の異常を使用しないでください。これらは、プログラムの移植性をさらに低下させるだけです。 DRM よりも優れています。

ああ、質問のタイトルに答えるには: いいえ。それは時間とお金の無駄であり、あなたの製品が私の強化された Linux システムで動作しなくなります。

于 2009-12-09T18:35:00.603 に答える