由于一般是根據 HTTP 協議在 Web 上傳輸 Atom 數據，因此要完全忽略潛在的安全隱患是不可能的。比如，聯合內容會顯示在多處而不是顯示在其原始點（畢竟，這正是聯合的意義所在），您如何證明其中一方未曾修改過數據？如果某些敏感數據只能由單一個體或組織獲悉怎么辦？當然，最明顯的例子就是銀行信息。您愿意通過原始的 HTTP feed 來接收銀行信息嗎？所有的敏感信息都存在這個問題，比如公司的內部信息。

這篇文章向大家介紹了如何使用數字簽名和加密來解決此類問題。

還記得兒時與伙伴們分享的秘密暗號嗎？您可以編制各種消息并對它們進行加密，您的伙伴可以使用暗號來解碼這些消息。他還可以使用暗號創建您能夠讀懂的消息。這就是共享密鑰（shared key）加密的一個例子，因為你們倆都有相同的暗號。

如今，這種方法能很好地防止消息內容被別人窺竊，稍后我將向大家介紹如何使用共享密鑰加密來實現這一目的。

但是，共享密鑰加密存在一個小問題。如果您接收到的一個加密消息告訴你使用雪球攻擊女子俱樂部的房子，您如何才能分辨該消息確實是來自您的伙伴，而不是附近不懷好意的人在捉弄您呢？還有，如果您向伙伴發送了一條消息，如何才能保證只有他能夠閱讀該消息？

在成年人的世界里，可以通過使用公鑰 — 私鑰 加密來解決此類問題。它使用的并不是一個密鑰，而是一個密鑰對（key pair）。也就是說，一個人加密的消息只能由另一個人解密，反之亦然。

其中一個密鑰是私有的，而另一個則是公有的，與其所有者相關。我們回到小孩的例子中，您的伙伴可以使用他的私鑰來加密進攻計劃。如果他的公鑰可以成功地解密該計劃，則您就能知道計劃是由他發送的。當然，由于他的公鑰是公有的，因此任何人都可以閱讀該消息。另一方面，他可以使用您的公鑰來加密消息，這就意味著只能使用您的私鑰來閱讀該消息。這種方法解決了安全問題，但是不能解決驗證問題。

真實世界中需要結合兩種技術來解決此類問題。比方說，可以對消息進行數字簽名。這一過程能使您確定消息的發送者以及消息在傳遞途中是否被修改過。把這種技術與直接加密技術結合使用，所有的問題就迎刃而解了。

我們先從加密 Atom 條目開始。

查看原文>>

http://www.ibm.com/developerworks/cn/xml/x-atomencryption/