Hiện nay, bảo mật tầng vận chuyển (TLS) là chuẩn phổ biến cho việc giao tiếp an toàn qua mạng. TLS là phương thức bảo mật đầu cuối - đầu cuối, phương thức này đi theo giao thức SSL nổi tiếng (giao thức Web dùng để thiết lập bảo mật giữa máy chủ và máy khách bằng cách mã hóa dữ liệu truyền ở mức IP socket). SSL đã được Netscape thiết kế đầu tiên và sau này phiên bản 3.0 của nó đã được đội tác nghiệp kỹ thuật Internet (IETF) sử dụng khi họ thiết kế TLS. Đây là một giao thức rất an toàn và đáng tin cậy, nó cung cấp các phiên giao dịch đầu cuối - đầu cuối an toàn giữa hai bên. XML Encryption không có ý định thay thế hay loại bỏ SSL/TLS. Đúng hơn là nó cung cấp một cơ chế cho các yêu cầu bảo mật không có trong SSL. Sau đây là hai lĩnh vực quan trọng mà không có trong SSL:

• Mã hóa một phần dữ liệu sẽ được trao đổi
• Các phiên giao dịch an toàn giữa nhiều hơn hai bên

Với XML Encryption, mỗi bên có thể duy trì trạng thái bảo mật hoặc không bảo mật với bất cứ nhóm giao tiếp nào. Cả dữ liệu bảo mật và không bảo mật đều có thể được trao đổi trong cùng văn bản. Ví dụ, hãy nghĩ về ứng dụng trò chuyện bảo mật, ứng dụng này chứa một số các phòng trò chuyện với một số người trong mỗi phòng. Các tệp đã được mã hóa XML có thể được trao đổi giữa những người tham gia trò chuyện do đó mà dữ liệu dành cho một phòng thì người ở những phòng khác sẽ không xem được.

XML Encryption có thể xử lý cả dữ liệu XML và không XML (ví dụ: dữ liệu nhị phân). Ở đây chúng ta sẽ minh họa một quá trình trao đổi dữ liệu đơn giản, làm cho việc trao đổi đó trở lên an toàn thông qua XML Encryption. Rồi chúng ta sẽ tăng dần độ phức tạp của các yêu cầu bảo mật và giải thích lược đồ XML Encryption và việc sử dụng các phần tử khác nhau của nó.

Một ví dụ đơn giản về việc trao đổi an toàn dữ liệu XML

Giả sử rằng bạn muốn gửi tệp XML trong Ví dụ 1 tới một công ty xuất bản. Tệp này chứa các thông tin chi tiết về cuốn sách bạn muốn mua. Hơn nữa nó cũng chứa thông tin thẻ tín dụng của bạn để dùng cho việc trả tiền. Đương nhiên, bạn sẽ muốn sử dụng cách giao tiếp an toàn cho dữ liệu nhạy cảm này. Có một lựa chọn là sử dụng SSL, cách này sẽ bảo mật với toàn bộ giao dịch. Có một lựa chọn khác là dùng XML Encryption. Như đã nói ở bên trên, XML Encryption không phải là phương thức thay thế cho SSL/TLS. Nếu ứng dụng yêu cầu bảo mật toàn bộ giao dịch thì bạn sẽ dùng SSL. Mặt khác, XML Encryption sẽ là lựa chọn tốt nhất nếu như ứng dụng yêu cầu sự kế hợp giữa giao dịch bảo mật và không bảo mật (điều này có nghĩa là một phần dữ liệu sẽ được trao đổi một cách an toàn và phần còn lại sẽ được trao đổi như nó hiện có).

                

<purchaseOrder>
	<Order>
		<Item>book</Item>
		<Id>123-958-74598</Id>
		<Quantity>12</Quantity>
	</Order>
	<Payment>
		<CardId>123654-8988889-9996874</CardId>
		<CardName>visa</CardName>
		<ValidDate>12-10-2004</ValidDate>
	</Payment>
</purchaseOrder>

Ghi chú: Chúng tôi đã cố tình để tệp XML trong Ví dụ 1 rất đơn giản. Điều này giúp chúng ta tập trung vào các vấn đề liên quan đến mã hóa. Các tệp XML trong thế giới thực trong hợp tác thương mại hoặc các dịch vụ Web sẽ tương tự về cấu trúc nhưng dài dòng hơn. WSDL (Ngôn ngữ định nghĩa dịch vụ Web) và SOAP (Phương thức truy cập đối tượng đơn giản) là các ngữ pháp dựa trên XML và chúng được sử dụng thường xuyên trong tích hợp B2B. Cả WSDL và SOAP đều có thể sử dụng XML Encryption để cung cấp các giao dịch an toàn giữa các công ty. Hãy ghé thăm W3C để biết thêm chi tiết về chúng (Xem Tài nguyên).

Mã hóa các tài liệu trọn vẹn với XML Encryption

XML Encryption cung cấp nhiều tùy chọn. Ví dụ 2, Ví dụ 3 và Ví dụ 4 thể hiện các kết quả của việc mã hóa khác nhau. Hãy xem xét chúng một cách chi tiết, từng ví dụ một.

Ví dụ 2 minh họa tệp kết quả sau khi đã được mã hóa XML, trong trường hợp bạn quyết định mã hóa toàn bộ tài liệu XML trong Ví dụ 1. Chú ý các thẻ <CipherData> và <CipherValue>. Dữ liệu được mã hóa thực sự xuất hiện như là nội dung của thẻ <CipherValue>. Phần tử CipherData trọn vẹn xuất hiện trong một phần tử EncryptedData. Phần tử EncryptedData chứa không gian tên XML được sử dụng cho việc mã hóa. Ví dụ, dữ liệu gốc của bạn trước khi mã hóa là XML và định nghĩa kiểu cho XML một cách chính thức bởi tổ chức có trách nhiệm phân số Internet (IANA) cho XML là http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml. Nó xuất hiện như là giá trị của thuộc tính Type. XML Encryption sử dụng các định nghĩa kiểu bởi IANA cho nhiều các định dạng dữ liệu phổ biến như là RTF, PDF, và JPG. Hãy tham khảo các trang Web của chúng để có thông tin đầy đủ (xem Tài nguyên). Nếu bạn có các kiểu dữ liệu ứng dụng đặc biệt (có thể là các DTD hoặc XSD của riêng bạn, chúng thuộc vào hệ thống quản lý nội dung của công ty bạn) bạn có thể chỉ ra trong thuộc tính Type của phần tử EncryptedData. Thuộc tính còn lại, xmlns, chỉ ra không gian tên XML Encryption mà chúng ta sử dụng để mã hóa dữ liệu XML.

Mã hóa một phần tử đơn với XML Encryption

Bạn có thể muốn mã hóa chỉ một phần tử trong Ví dụ 1 -- ví dụ, phần tử Payment. Trong trường hợp này, kết quả được minh họa trong Ví dụ 3. So sánh Ví dụ 2 và Ví dụ 3 bạn sẽ thấy các điểm khác biệt sau đây:

1. Ví dụ 2 chỉ chứa lược đồ của XML Encryption, trong khi Ví dụ 3 chứa cả XML Encryption và các thành phần từ dữ liệu gốc trong Ví dụ 1. Trong Ví dụ 3, XML Encryption được nhúng trong XML của người dùng.
2. Ví dụ 3 cũng có thuộc tính Type trong <EncryptedData>, nhưng giá trị của nó là http://www.w3.org/2001/04/xmlenc#Element. Chúng ta không còn sử dụng kiểu IANA nữa mà thay vào đó chúng ta đang sử dụng kiểu mà XML Encryption đã chỉ ra.
3. Đặc biệt chú ý đến đoạn #Element ở cuối có nghĩa là EncryptedData -- nó thay thế một phần tử.

Mã hóa nội dung của một phần tử

Ví dụ 4 sẽ là kết quả nếu bạn muốn chỉ mã hóa nội dung trong CardId, một phần tử trong Ví dụ 1. Lần này, chúng ta đã sử dụng http://www.w3.org/2001/04/xmlenc#Content làm giá trị thuộc tính Type. Chúng ta sẽ sử dụng giá trị này bất cứ khi nào chúng ta phải mã hóa chỉ phần nội dung.

Mã hóa dữ liệu không phải XML

Nếu bạn muốn gửi, giả sử, một tệp JPEG thông qua XML Encryption thì sẽ thế nào? Ví dụ 5 là một tệp kết quả điển hình. Tệp JPEG hoàn chỉnh là một chuỗi đã được mã hóa các byte và sẽ xuất hiện như là nội dung của phần tử CipherValue. Chú ý rằng chỉ có một điểm khác biệt giữa Ví dụ 2 và Ví dụ 5: thuộc tính Type của phần tử EncryptedData. Ví dụ 5 bao gồm kiểu IANA cho định dạng JPEG. Tương tự, bạn có thể mã hóa bất cứ định dạng nào bằng cách cung cấp các giá trị IANA (tham khảo trang Web IANA, xem Tài nguyên).

Về đầu trang

Các khóa cho XML Encryption

Trong các ví dụ từ 1 đến 5, chúng ta đã minh họa việc mã hóa, việc này sẽ không thể thực hiện nếu không có các khóa (xem bảng ở bên các khóa công cộng, riêng và bí mật). Với XML Encryption, tất cả các vấn đề liên quan tới khóa được chia thành hai phần:

• Trao đổi các khóa (mã hóa không đối xứng)
• Sử dụng các khóa đã được trao đổi trước (mã hóa đối xứng)

Với cách này, người dùng có thể trao đổi các khóa với nhau trước và sau đó mới dùng chúng.

Các khóa không đối xứng cho việc trao đổi khóa bí mật

Ở trong ngữ cảnh này, một bên gửi khóa công cộng của nó cho bên thứ hai. Bên thứ hai sử dụng khóa công cộng này để mã hóa khóa bí mật của nó. Việc trao đổi dữ liệu này được minh họa trong Ví dụ 6 (yêu cầu) và Ví dụ 7 (phản hồi). Chúng ta sẽ tưởng tượng rằng Imran và Ali là bên thứ nhất và thứ hai một cách tương ứng, họ giao tiếp với nhau. Imran khởi tạo yêu cầu trao đổi khóa công cộng và gửi khóa công cộng của anh ấy trong phần tử có tên là KeyValue. Thuộc tính CarriedKeyName thể hiện tên của khóa đang được vận chuyển. Chú ý rằng phần tử gốc của cấu trúc này là EncryptedKey, phần tử này chứa các phần tử ds:KeyInfo và ds:KeyValue. Các phần tử ds: KeyInfo và ds:KeyValue thuộc vào không gian tên chữ kí số XML (ds:). XML Encryption phụ thuộc hoàn toàn vào đặc tả chữ ký số XML cho việc trao đổi khóa. Vì vậy, cả <ds:EncryptedKey> và <ds:KeyValue> phụ thuộc vào không gian tên đặc tả chữ ký số XML. Ví dụ 7 là cái mà Ali gửi phản hồi. Phần tử CipherValue trong Ví dụ 7 chứa khóa bí mật mới được tạo ra, khóa này đã được mã hóa với khóa công cộng của bên thứ nhất. Quan sát kỹ Ví dụ 6 và Ví dụ 7, bạn sẽ nhận ra rằng cả yêu cầu và phản hồi đều chứa một phần tử EncryptedKey. Các phần tử ds:KeyInfo và ds:KeyValue bên trong phần tử EncryptedKey chứa khóa công cộng (Ví dụ 6). Mặt khác, các phần tử CipherData và CipherValue trong phần tử EncryptedKey (Ví dụ 7) sẽ vận chuyển các khóa bí mật (đã được mã hóa). Cũng chú ý rằng phần tử EncryptedKey luôn luôn chứa thuộc tính CarriedKeyName để chỉ ra tên của khóa mà nó đang mang.

Sử dụng các khóa mà chúng ta đã trao đổi

Trong phần trước, chúng ta đã trao đổi một khóa bí mật. Giờ thì chúng ta sẽ sử dụng khóa đó để mã hóa dữ liệu. chúng ta sẽ giả sử rằng Imran gửi đi một đoạn tin XML (Ví dụ 8) để đáp lại Ví dụ 7 (nhớ lại rằng Ví dụ 7 chứa một khóa bí mật đã được mã hóa và tên của nó là "Imran Ali"). Imran sẽ giải mã khóa bí mật này với khóa riêng của anh ấy (của chính Imran) (bởi vì Ali đã mã hóa khóa bí mật này với khóa công cộng của Imran). Imran có thể sử dụng khóa bí mật này mã hóa dữ liệu mà anh ấy muốn gửi cho Ali và đặt đoạn mã vào trong phần tử CipherValue trong Ví dụ 8.

Phần tử ds:KeyInfo trong Ví dụ 8 chứa một phần tử KeyName. Việc kết hợp này chỉ tới tên của khóa mà Imran sử dụng cho việc mã hóa dữ liệu.

Hình 1 là một lược đồ trực quan thể hiện việc trao đổi các tệp XML cho việc trao đổi dữ liệu an toàn này.

Tham chiếu tới dữ liệu đã được mã hóa bên ngoài từ tệp XML Encryption của chúng ta

Trong các ví dụ 5 và 7, phần tử CipherData có thể xuất hiện trong một phần tử EncryptedData hoặc phần tử EncryptedKey. Chúng ta sử dụng phần tử CipherData để nói đến cả dữ liệu đã được mã hóa (khi nó xuất hiện trong một phần tử EncryptedData) hoặc khóa đã được mã hóa (khi nó xuất hiện trong phần tử EncryptedKey). Trong cả hai ví dụ 5 và 7, đều có phần tử con CipherValue bên trong phần tử CipherData phần tử con này chứa dữ liệu đã được mã hóa thực sự.

Chúng ta cũng có thể đề cập tới dữ liệu hoặc các khóa được mã hóa bên ngoài. Điều này có nghĩa là dữ liệu hoặc các khóa được mã hóa thực sự sẽ được thể hiện ở đâu đó (có thể là đâu đó trên mạng) mà không phải là trong tệp XML Encryption của chúng ta. Trong trường hợp này chúng ta sẽ sử dụng CipherReference thay vì phần tử con CipherValue trong CipherData. Chúng ta sẽ đề cập tới dữ liệu được mã hóa thực sự thông qua một URI. Điều này được thể hiện trong Ví dụ 9.

Tham chiếu tới một phần tử cụ thể của một tệp XML bên ngoài

Ví dụ 10 minh họa một cách khác để tham chiếu tới các XML ở bên ngoài. Ở đây chúng ta mới chỉ tham chiếu tới một phần của tệp bên ngoài mà URI trỏ tới. Có một phần tử con Transforms ở trong phần tử CipherReference. Phần tử Transforms này có thể chứa một số phần tử Transform, mỗi phần tử này sẽ chứa một phần tử XPath đơn. Phần tử XPath đơn này chỉ ra biểu thức XPath tham chiếu tới một nút cụ thể của tài liệu XML ở ngoài.

Về đầu trang

Cấu trúc DOM của API của chúng ta

Chúng ta đã minh họa cách tạo ra các tệp XML Encryption và trao đổi dữ liệu mã hóa. Bây giờ chúng ta sẽ đề xuất một Java API cho XML Encryption và cung cấp một thực thi ví dụ. Chúng ta sẽ sử dụng DOM cho mục đích này.

Thực thi DOM của chúng ta bao gồm một tập các lớp (các ví dụ từ 11 tới 16). Lớp XmlEncryption (Ví dụ 11) là phần bao bọc cho các lớp còn lại, điều này có nghĩa là người dùng API của chúng ta sẽ chỉ cần tương tác với lớp này. Nó sử dụng chức năng của các lớp khác ở bên trong.

Ví dụ 11 là một lớp bao bọc, nó có thể tạo ra một tệp mã hóa XML hoàn chỉnh.

Ví dụ 12 tạo ra phần tử EncryptedData.

Ví dụ 13 tạo ra phần tử EncryptionMethod.

Ví dụ 14 tạo ra phần tử KeyInfo.

Ví dụ 15 tạo ra phần tử CipherData .

Ví dụ 16 chứa tên của các thuật toán như là các số nguyên tĩnh và các không gian tên tương ứng của chúng dưới dạng các chuỗi ký tự.

Lớp XmlEncryption (Ví dụ 11) chứa các phương thức Get/Set công cộng. Người dùng sẽ gọi các phương thức Set để chỉ ra các tham số mã hóa, bao gồm:

1. Tên của tệp sẽ được mã hóa
2. Tên của tệp XML Encryption kết quả
3. Tên của thuật toán mã hóa
4. Tên của khóa sẽ sử dụng cho việc mã hóa
5. Một ID (mã số) để nhận biết cấu trúc <EncryptedData>

Chúng ta đã minh họa việc sử dụng lớp XmlEncryption (Ví dụ 11) thông qua phương thức main (). Trong phương thức main (), chúng ta đã tạo ra một trường hợp của lớp này. Bộ phận cấu thành đã minh họa DOM, do đó toàn bộ các lớp bên dưới sẽ sử dụng cùng một đối tượng.

Việc thực hiện này chỉ hỗ trợ việc mã hóa các tệp hoàn chỉnh, như minh họa trong Ví dụ 2. Phương thức EncryptCompleteXmlFile() sẽ làm điều này bằng cách gọi tuần tự các phương thức sau:

1. GetEncryptedDataDoc() trả về đối tượng của lớp EncryptedData (Ví dụ 12). Nó chứa cấu trúc của phần tử EncryptedData.
2. GetEncryptionMethodDoc() trả về đối tượng tài liệu chứa cấu trúc XML tương ứng với phần tử EncryptionMethod. GetEncryptionMethodDoc() sử dụng lớp EncryptionMethod (Ví dụ 13) để tạo ra XML.
3. GetKeyInfoDoc() trả về đối tượng Document chứa cấu trúc XML tương ứng với phần tử KeyInfo. GetKeyInfoDoc() sử dụng đối tượng của lớp GenericKeyInfo (Ví dụ 14) để tạo ra XML. Lớp này chỉ cung cấp các chức năng cần thiết tối thiểu (hỗ trợ cho các phần tử KeyName và KeyValue) bạn sẽ kế thừa từ lớp GenericKeyInfo để cung cấp chức năng hoàn chỉnh, bao gồm hỗ trợ cho các xác thực X509, dữ liệu PGP, v.v...
4. ReadFile() tìm nạp dữ liệu (tệp XML hoàn chỉnh) mà chúng ta muốn mã hóa.
5. GetEncryptedData() không làm gì tại thời điểm hiện tại. Chúng ta sẽ chạy phương thức này trong phần sau của bài viết. Nó có nhiệm vụ tạo ra mẫu mã hóa cho dữ liệu XML mà chúng ta đã tìm nạp trong bước 4. Chúng ta đã thảo luận một cách vắn tắt về chiến lược mã hóa của mình trong phần trước (Java Cryptographic Architecture - Kiến trúc mã hóa Java).
6. GetCipherDataDoc() lấy đối số là dữ liệu đã được mã hóa và trả lại đối tượng Document chứa phần tử CipherData. GetCipherDataDoc() sử dụng đối tượng của lớp CipherData (Ví dụ 12) để tạo ra XML.
7. Cuối cùng, phương thức addChild() của đối tượng của EncryptedData (Ví dụ 15) sẽ được gọi ba lần và sẽ lấy các đối tượng Document của các bước 2, 3 và 6 và thêm chúng vào cấu trúc <EncryptedData>, cha của tất cả chúng.
8. SaveEncryptedFile() lưu tệp XML Encryption hoàn chỉnh.

AlgoNames (Ví dụ 16) là một lớp trợ giúp, lớp này chỉ chỉ ra các định nghĩa không gian tên được yêu cầu bởi XML Encryption.

Lớp XmlEncryption (Ví dụ 11) cũng có thể được sử dụng như là thành phần bên phía máy chủ. Trong phần tiếp theo của chuỗi bài này, chúng ta sẽ minh họa việc sử dụng chúng trong các ứng dụng độc lập cũng như các ứng dụng phía máy chủ.

Tập hợp các lớp mà chúng ta đã phát triển chỉ thực hiện việc tạo ra XML dựa trên DOM. Chúng ta cũng cần phải thực hiện chức năng mã hóa. Bây giờ chúng ta sẽ cố tạo ra một chiến lược để trợ giúp mã hóa. Với mục đích này thì chúng ta cần học Java Cryptographic Architecture (JCA) - Kiến trúc mã hóa Java.

Về đầu trang

Kiến trúc mã hóa Java - Java Cryptographic Architecture (JCA)

Java cung cấp trợ giúp hoàn chỉnh cho việc mã hóa. Có một số gói trong J2SE cho mục đích này bao trùm tất cả các đặc tính chính của kiến trúc bảo mật như là điều khiển truy cập, chữ ký, xác thực, cặp khóa, kho khóa, và các chuỗi các chữ số đơn thể hiện văn bản.

Phương thức chính của thiết kế JCA là tách các khái niệm mã hóa ra khỏi các bước thực thi thuật toán, do vậy mà các nhà cung cấp khác nhau có thể cung cấp các công cụ của họ trong cùng khung làm việc JCA.

Các lớp JCA Engine

JCA định nghĩa một loạt các lớp Engine, trong đó mỗi Engine cung cấp một hàm mã hóa. Ví dụ, có một số chuẩn khác nhau của thuật toán MD (sinh chuỗi chữ số đơn thể hiện văn bản). Tất cả các chuẩn này khác nhau về cách thực hiện nhưng ở mức giao diện lập trình ứng dụng Engine thì tất cả đều giống nhau. Các nhà cung cấp khác nhau tự do trong việc cung cấp các cách thực thi khác nhau của các thuật toán đặc biệt.

Mở rộng mã hóa Java - Java Cryptographic Extension (JCE)

Tất cả các thực thi của các thuật toán mã hóa của nhà cung cấp độc lập (bên thứ ba) được gọi là các mở rộng mã hóa Java - Java Cryptographic Extensions (JCEs). Sun Microsystems cũng đã cung cấp một thực thi cho JCE. Bất cứ khi nào sử dụng JCE chúng ta phải định cấu hình cho nó với JCA. Để làm việc này chúng ta phải:

1. Thêm vào địa chỉ của tệp jar để xác định nhà cung cấp (tất cả các thực thi JCE được gọi là các nhà cung cấp) trong các biến môi trường CLASSPATH.

2. Xác định nhà cung cấp trong danh sách các nhà cung cấp đã được thông qua bằng cách sửa tệp java.security. Tệp này được đặt tại thư mục JavaHome/jre/lib/security. Dưới đây là cú pháp để chỉ ra độ ưu tiên: security.provider.<n>=<masterClassName>. Ở đây n là số ưu tiên (1, 2, 3, v.v..). MasterClassName là tên của lớp chủ mà các lớp engine sẽ gọi để thực thi một thuật toán cụ thể. Tài liệu của nhà cung cấp sẽ chỉ ra tên lớp chủ của nó. Ví dụ, xem xét các mục vào dưới đây trong một tệp java.security:

• security.provider.1=sun.security.provider.Sun
• security.provider.2=com.sun.rsajca.Provider
• security.provider.3=com.sun.net.ssl.internal.ssl.Provider

Các mục vào này có nghĩa là lớp engine sẽ tìm bất kỳ việc thực thi thuật toán nào theo trật tự nói trên. Nó sẽ thực hiện việc thực thi được tìm thấy trước tiên. Sau các bước đơn giản này, tất cả chúng ta đã thiết lập để sử dụng JCA/JCE trong ứng dụng XML Encryption của mình.

Sử dụng JCA và JCE trong các thực thi XML Encryption của chúng ta

Hàm GetEncryptedData() trong lớp bao phủ của bạn, XmlEncryption (Ví dụ 11), là nơi xử lý tất cả các vấn đề liên quan tới JCA/JCE. Hiện tại thì phương thức này chỉ trả lại chuỗi ký tự "This is Cipher Data" (đây là dữ liệu mã hóa). Chúng ta vẫn chưa viết các lớp liên quan tới JCA/JCE. Phương thức này lấy dữ liệu không mã hóa và trả lại dữ liệu đó dưới dạng một xâu ký tự đã được mã hóa. Chúng ta sẽ xử lý tất cả các vấn đề liên quan tới thuật toán và khóa trong phương thức này sau khi viết các lớp bao phủ cho JCA/JCE.

Lần tới: Trong phần tiếp theo của chuỗi bài viết này, chúng ta sẽ thảo luận và thực hiện các chi tiết của mã hóa. Chúng ta sẽ minh họa sự làm việc của các lớp mã hóa và giải mã và tương tác của chúng với lôgíc phân tích cú pháp và các ứng dụng hiện tại của XML Encryption trong các dịch vụ Web.

Tài nguyên

• Đọc "Khám phá XML Encryption, Phần 2" của chuỗi gồm 2 bài viết này của Bilal Siddiqui về XML Encryption (developerworks - các công việc của lập trình viên, tháng 8 năm 2002).
  
  
• Thăm W3C để xem các chi tiết chính thức của Các yêu cầu XML Encryption và Cú pháp và xử lý XML Encryption.
  
  
• Xem các thông tin về XML Encryption tại các trang bìa XML của OASIS/Robin Cover.
  
  
• Bộ công cụ của IBM cho XML Encryption có cho tải về tại alphaWorks.
  
  
• Kiểm tra xem cái gì đang diễn ra tại Sự tiến bộ cộng đồng của SUN cho XML Encryption.
  
  
• Chúng tôi đã nhắc đến XPath trong bài viết này. Đây là một chương về XPath từ một cuốn sách XML in a Nutshell - Tóm tắt về XML được viết bởi O'Reilly.
  
  
• Chúng tôi đã đề cập đến IANA trong bài viết này. Hãy ghé thăm trang Web của IANA để xem các định nghĩa của các định dạng dữ liệu phổ biến.
  
  
• IBM Security Services - Các dịch vụ bảo mật IBM có thể giúp bạn xác định xem các mối nguy hiểm của bạn là gì, rồi sau đó thiết kế một chương trình bảo mật để giải quyết các mối nguy hiểm đó.
  
  
• WebSphere Studio Application Developer (nhà phát triển ứng dụng WebSphere Studio) của IBM là một môi trường phát triển dễ sử dụng và tích hợp cho việc xây dựng chương trình, kiểm tra và triển khai các ứng dụng J2EE (TM), bao gồm việc tạo ra các tài liệu XML từ các DTD và lược đồ.
  
  

Đôi nét về tác giả

Chấm điểm bài này

Bình luận

Về đầu trang

Mục lục

• Một ví dụ đơn giản về việc trao đổi an toàn dữ liệu XML
• Các khóa cho XML Encryption
• Cấu trúc DOM của API của chúng ta
• Kiến trúc mã hóa Java - Java Cryptographic Architecture (JCA)
• Tài nguyên
• Đôi nét về tác giả
• Bình luận