CBC-MAC长度扩展攻击的IV仿真

Question

我正在做密码挑战(以前的Matasano挑战)，在第49问题的第二部分中，我被要求在没有IV操作的情况下使用CBC进行长度扩展攻击。有一种暗示，我可以用某种方式来模拟IV，但我不明白。至少有人能给我点提示吗？我通过修改IV来伪造消息的第一个块。

特别是有这样一种消息格式

  from=#{from_id}&tx_list=#{transactions}

将事务列表格式化如下：

  to:amount(;to:amount)*

任务是:从目标用户获取有效消息。使用长度扩展添加支付攻击者帐户100万空格的事务。

编辑好了，因为我没有用我自己的话正确地解释它，这是原来的问题

49. CBC-MAC Message Forgery

Let's talk about CBC-MAC.

CBC-MAC is like this:

  1. Take the plaintext P.
  2. Encrypt P under CBC with key K, yielding ciphertext C.
  3. Chuck all of C but the last block C[n].
  4. C[n] is the MAC.

Suppose there's an online banking application, and it carries out user
requests by talking to an API server over the network. Each request
looks like this:

  message || IV || MAC

The message looks like this:

  from=#{from_id}&to=#{to_id}&amount=#{amount}

Now, write an API server and a web frontend for it. (NOTE: No need to
get ambitious and write actual servers and web apps. Totally fine to
go lo-fi on this one.) The client and server should share a secret key
K to sign and verify messages.

The API server should accept messages, verify signatures, and carry
out each transaction if the MAC is valid. It's also publicly exposed -
the attacker can submit messages freely assuming he can forge the
right MAC.

The web client should allow the attacker to generate valid messages
for accounts he controls. (Feel free to sanitize params if you're
feeling anal-retentive.) Assume the attacker is in a position to
capture and inspect messages from the client to the API server.

One thing we haven't discussed is the IV. Assume the client generates
a per-message IV and sends it along with the MAC. That's how CBC
works, right?

Wrong.

For messages signed under CBC-MAC, an attacker-controlled IV is a
liability. Why? Because it yields full control over the first block of
the message.

Use this fact to generate a message transferring 1M spacebucks from a
target victim's account into your account.

I'll wait. Just let me know when you're done.

~ waiting ~

~ waiting ~

~ waiting ~

All done? Great - I knew you could do it!

Now let's tune up that protocol a little bit.

As we now know, you're supposed to use a fixed IV with CBC-MAC, so
let's do that. We'll set ours at 0 for simplicity. This means the IV
comes out of the protocol:

  message || MAC

Pretty simple, but we'll also adjust the message. For the purposes of
efficiency, the bank wants to be able to process multiple transactions
in a single request. So the message now looks like this:

  from=#{from_id}&tx_list=#{transactions}

With the transaction list formatted like:

  to:amount(;to:amount)*

There's still a weakness here: the MAC is vulnerable to length
extension attacks. How?

Well, the output of CBC-MAC is a valid IV for a new message.

"But we don't control the IV anymore!"

With sufficient mastery of CBC, we can fake it.

Your mission: capture a valid message from your target user. Use
length extension to add a transaction paying the attacker's account 1M
spacebucks.

HINT:

  This would be a lot easier if you had full control over the first
  block of your message, huh? Maybe you can simulate that.

Food for thought:

  How would you modify the protocol to prevent this?

Answer 1

所有这些关于IV的讨论似乎只是为了迷惑读者。忽略IV.你只需对CBC做一个简单的长度扩展攻击.是的，一条信息就够了。