第二章 系統架構與協定
第四節 競標階段
第一小節 直覺解
本小節中我們先提出一個直覺解法，然後我們會一一討論可能發生的問題。
一般在投標的過程中，拍賣者跟投標者只需要一來一往的訊息交換就可以達到目 的，也就是兩步驟的協定。
9 Bidder
Auctioneer 我是 Bob，下標 A 商品 300 元
BidACKi BidQi 下標成功
圖 1 兩步驟協定示意圖
Step 1: 投標者傳送投標的請求訊息（BidQi）給拍賣者。BidQi=(ItemID, UserID, Price, [ItemID, UserID, Price]pri(U))，其中 ItemID 是商品編號，
UserID 為投標者的會員編號，Price 則是標價。
Step 2: 拍賣者收到 BidQi後檢查上面的電子簽章正確與否，並且核對投標 者的會員編號有沒有對應到驗證電子簽章的個人資訊，接著用商品編號 比較該商品目前的出價是否比標價低，並回傳確認訊息（BidACKi）給投 標者。拍賣者會拿雜湊鏈中最新的雜湊值（CHi-1）與Qi一起放進雜湊函 數做計算（hash(Qi, CHi-1)），把計算出的雜湊值（CHi）加入雜湊鏈並更 新到公布欄上供投標者檢驗，如圖 2 (A) 所示。BidACKi=(BidSuccess, CHi, [BidSuccess, CHi]pri(Auctioneer))，BidSuccess 則代表投標是否成功，電 子簽章驗證錯誤或者出價較低的話則投標失敗。
• 初始化雜湊鏈
• Initial hash=“0000000”
• 收到投標訊息 BidQ1
• Hash(BidQ1, IH)=CH1=“5d3a272”
• 商品 132 標價為 1000
11
二，假設賣家設定此商品的起標價為一萬元，但其實他希望至少要賣到二十萬，
他可以與拍賣者協商：每當有人投標就先去檢查 BidQi的標價為何，若是比二十 萬低，那拍賣者就即時產生一個假投標，標價與此投標相當，導致該投標者下標 失敗，直到有人出高於二十萬為止，我們把這種做法歸類為 [14] 中的 Shill bidding。
第三，對於同一場拍賣會而言，拍賣者一次只能接受一筆投標請求訊息。我 們使用雜湊鏈記錄所有投標請求訊息，雜湊鏈一次只能新增一條紀錄進去，因此 新增時必須被同步處理。這個限制會導致投標者在網路壅塞的環境中投標時，拍 賣者無法同時處理來自其他投標者對同一商品的投標，假如有人故意以近乎於零 的傳輸速率傳送投標請求訊息，其他投標者的動作都必須卡在原地，若他遲遲不 完成投標，這個拍賣會將被癱瘓，我們將此種惡意手段稱為 Slow-running attack [20]。
第二小節 改良法
前一小節提到 Briber bids 與 Shill bidding 的根本問題在於 BidQi的內容沒有 加密，如果我們將UserID 與 Price 都先變成密文後才下標，那麼拍賣者就沒有辦 法在一開始得知投標者的身分進而偏袒特定使用者。然而，把資訊都加密之後，
投標者勢必要告訴拍賣者用來解密的密碼為何，那麼兩步驟的協定無法滿足這個 需求，因此我們把他改進為四步驟的協定。然而，在投標者回傳解密的金鑰時，
為了防止拍賣者假裝沒收到，我們多設置了一個離線的可信任第三方（Offline Trusted Third Party [10]），以佐證投標者是否傳送該含有解密金鑰的訊息。
Bidder 資料包通訊協定（User Datagram Protocol，簡寫為 UDP）傳送給拍賣者。
BidQi=(ItemID, {UserID}enc(U, k1), {Price}enc(U, k2), [ItemID, {UserID}enc(U, k1), {Price}enc(U, k2)]pri(AK)2)，其中 ItemID 為商品編號，UserID 為投標者的會
13
Step 3: 當投標者收到 BidRi後，去驗證裡面的電子簽章是否有效，然後比 對公佈欄上是否存在BidQi和CHi-1，接著用BidQi跟CHi-1計算出CHi以 驗證更新後的雜湊鏈，如果正確的話就把用來加密 BidQi 中 UserID 及 Price 的鑰匙 k1, k2 與 BidRi做成回覆回應訊息（Reply-response message，
簡寫為BidRRi）傳給拍賣者，BidRRi=(k1, k2, BidRi, [k1, k2, BidRi]pri(U))。
如果沒有立即收到拍賣者的回應，那麼投標者可以再傳送一次BidRRi並 且另外傳送一份副本給離線的可信任第三方。
Step 4: 拍賣者收到 BidRRi後，首先檢查其中的電子簽章，接著嘗試用 k1 與 k2 分別解開 BidQi裡面的UserID 跟 Price，並且將用來加密 Price 的 k2 與解密後的 Price 公佈於公布欄上，供所有人來驗證此次出價的正確 性 ， 最 後 把 他 們 製 作 成 確 認 訊 息 （BidACKi） 回 傳 給 投 標 者 ， BidACKi=(UserID, Price, BidSuccess, BidRRi, [UserID, Price, BidSuccess, BidRRi]pri(Auctioneer))。若拍賣者在公佈 BidQi及 CHi後，等待時間超過拍 賣會初始化所公布的時限值都沒有收到BidRRi，首先去離線的可信任第 三方檢查是否存在該BidRRi，否則此次投標變成廢標，拍賣者必須立刻 在公佈欄上發布此作廢訊息。
在第一個步驟中，BidQi的電子簽章是用拍賣會初始化階段中所得到的AK 來 簽署，這樣可以確保投標者都有經過該前一個階段的認證，拍賣者可以直接過濾 掉一些外來的惡意投標，但是也無法由電子簽章判斷投標者的身分。
這個改良過後的四步驟投標協定解決了原本碰到的三個問題，拍賣者在收到
• Initial hash=“0000000”
• Timeout 為 3 秒
• 收到投標訊息 BidQ1
• Hash(BidQ1, IH)=CH1=“c798b4a”
• 收到投標回覆回應訊息 BidRR1
15
任第三方也查詢不到該筆BidRRi時，拍賣者將會在公佈欄上標註這是一個超時的 廢標。另一方面，如果投標者有在時限內送出BidRRi卻被公佈為廢標，那麼他可 以找離線的可信任第三方向拍賣者提出申訴。
我們將BidQi的大小限制在512 位元組內 [7]，可以被一個 UDP 封包所容納，
這樣一來就算在壅塞的網路中，只要送一個UDP 封包就完成投標的第一步驟，拍 賣者免去了等待後續封包抵達的同步處理，可以立刻將 BidQi加進雜湊鏈中，繼 續接受其他使用者的投標。