Trong thời đại công nghệ thông tin hiện nay, xác thực vẫn là một trong những mục tiêu quan trọng nhất của an toàn thông tin. Trong chủ đề này, vấn đề xác thực có thể được giới thiệu một cách cơ bản ở hai phạm trù:
Các kỹ thuật xác thực: Những kỹ thuật này bao gồm các cơ chế và thiết kế giao thức rất cơ sở cho xác thực thông báo và thực thể. Ở đây, những kỹ thuật xác thực cơ sở, những cơ chế đã được chuẩn hoá bởi những tổ chức tiêu chuẩn quốc tế sẽ được đề cập đến. Ngoài ra cũng sẽ giới thiệu thêm một số giao thức thiết lập khoá có xác thực và các giao thức xác thực khác như những ứng dụng.
Những khiếm khuyết của giao thức: Đây là một phần không thể thiếu trong chủ đề xác thực. Các tấn công điển hình đã biết và có thể được áp dụng trên những giao thức xác thực khác nhau cần được giới thiệu. Những khiếm khuyết giao thức điển hình và những kỹ thuật tấn công liên quan rất có ích cho người thiết kế giao thức.
Có thể nói, xác thực là một thủ tục mà qua nó, một thực thể thiết lập một thuộc tính được khai báo cho một thực thể khác. Như vậy, xác thực bao hàm ít nhất hai thực thể khác nhau trong liên lạc. Thông thường, việc liên lạc giữa những thực thể hợp tác với nhau được thực hiện theo một quy tắc nhất định được gọi là giao thức. Do đó một thủ tục xác thực được gọi là giao thức xác thực. Cần chú ý rằng, một thủ tục nói chung có thể không cần có hai thực thể tham gia, nhưng trong giao thức nhất thiết phải có hai thực thể tham gia.
Khái niệm xác thực có thể được chia ra làm hai loại: Xác thực nguồn gốc dữ liệu và xác thực thực thể. Khái niệm thứ nhất liên quan đến kiểm tra tính hợp lệ của thuộc tính được khai báo của thông báo, khái niệm thứ hai chú ý đến việc kiểm tra tính hợp lệ danh tính được khai báo của thực thể truyền thông báo. Trong một số ứng dụng, người ta có thể phối hợp cả hai loại xác thực này nhằm đạt những mục đích nhất định.
1. Xác thực nguồn gốc dữ liệu
Xác thực nguồn gốc dữ liệu  còn được gọi là xác thực thông báo, liên quan nhiều tới nguyên vẹn dữ liệu. Tuy nhiên, đây là hai khái niệm khác nhau, chúng có thể được phân biệt rõ ràng qua một số khía cạnh sau đây.
Thứ nhất, xác thực nguồn gốc dữ liệu gắn liền với liên lạc. Nó có mục đích kiểm tra xem thông báo có phải đến từ nguồn đã khai báo hay không. Còn nguyên vẹn dữ liệu không cần đến đặc tính liên lạc mà nó có thể được cung cấp ngay trên dữ liệu  lưu trữ.
Thứ hai, xác thực nguồn gốc dữ liệu phải bao gồm sự nhận biết nguồn gốc của thông báo, còn nguyên vẹn dữ liệu với tư cách là một dịch vụ an toàn có thể được cung cấp, không cần nhận biết nguồn gốc thông báo.
Thứ ba và có ý nghĩa hơn cả là xác thực nguồn gốc dữ liệu bao gồm sự thiết lập “tính tươi” của thông báo trong khi đó nguyên vẹn dữ liệu lại không cần làm như vậy: một đoạn dữ liệu cũ cũng có thể có tính nguyên vẹn hoàn hảo. Trong dịch vụ xác thực nguồn gốc dữ liệu, bên nhận thông báo phải kiểm tra xem thông báo này có đủ mới hay không (tức là khoảng thời gian giữa phát và thu thông báo là đủ nhỏ). Thông báo mà bên nhận cho là mới thường được đề cập đến như là một thông báo “tươi”. Việc đòi hỏi thông báo phải tươi có ý nghĩa phổ biến là, thông báo tươi kéo theo sự đáp ứng tốt giữa những thực thể liên lạc và điều này có thể suy luận đến tình huống ít khả năng hơn là khi những thực thể liên lạc, máy móc, những hệ thống hay bản thân thông báo có thể đã bị phá hoại rồi.
Khoảng thời gian để xác định tính tươi của thông báo được xác định bởi các ứng dụng cụ thể. Một số ứng dụng đòi hỏi khoảng thời gian đó dao động trong khoảng vài giây. Một số ứng dụng cho phép chu kỳ tươi dài hơn. Chẳng hạn, thời gian sống (life time) của séc ngân hàng là khoảng thời gian giữa ngày phát hành séc và ngày chi trả séc. Đa số các ngân hàng cho phép khoảng thời gian ba tháng là thời gian sống hợp lệ của séc.
Cuối cùng, cần chỉ ra rằng một sự xác nhận nặc danh nào đó được tạo bởi một vài sơ đồ mật mã (ví dụ chữ ký mù) cũng giúp phân biệt rõ ràng giữa xác thực nguồn gốc dữ liệu và nguyên vẹn dữ liệu. Người sử dụng được cấp một “giấy” xác nhận nặc danh để chứng minh tư cách thành viên với hệ thống. Tại đây, bằng chứng về sự nguyên vẹn dữ liệu có thể được trình diễn theo cách hợp lý, sống động, tuy nhiên hành động của hệ thống nhằm nhận biết nguồn gốc dữ liệu sẽ bị ngăn chặn.
2. Xác thực thực thể
Xác thực thực thể là một quá trình, trong đó một thực thể thiết lập sự “đáp ứng sống” với một thực thể khác, sao cho danh tính được khai báo của thực thể thứ hai phải đáp ứng được điều mà thực thể thứ nhất yêu cầu. Dưới đây là một vài kịch bản xác thực thực thể thông thường trong các hệ thống phân tán.
Trạm tới trạm (host-host): Các bên liên lạc là những máy tính, chúng được gọi là những “nút” hay “nền” trong hệ thống phân tán. Ví dụ, trong “khởi động” từ xa của một nút, khi khởi động, nút phải nhận biết trạm chủ tin cậy để cung cấp thông tin cần thiết như bản sao tin cậy của hệ điều hành, thiết lập đồng hồ tin cậy hay các thiết lập môi trường tin cậy hiện hành. Sự thiết lập thông tin tin cậy thường đạt được thông qua giao thức xác thực. Trường hợp thông thường, kiểu liên lạc trạm tới trạm là thiết lập chủ - khách khi một trạm khách yêu cầu những dịch vụ nào đó từ trạm chủ.
Người sử dụng tới trạm: Người sử dụng truy cập đến hệ thống máy tính bằng cách đăng nhập vào trạm trong hệ thống. Trong một số ứng dụng, khi một trạm bị tổn thương sẽ gây ra sự mất mát nghiêm trọng (chẳng hạn, khi người sử dụng thực hiện thanh toán tiền điện tử qua thẻ thông minh) thì xác thực lẫn nhau là cần thiết.
Tiến trình tới trạm: Ngày nay, tính toán phân tán đã tiến bộ cao đến mức rất nhiều chức năng và dịch vụ đặc biệt có thể thực hiện được. Một trạm có thể cấp cho tiến trình bên ngoài nhiều kiểu quyền truy cập khác nhau. Trong những ứng dụng nhạy cảm, cần phải thiết kế những cơ chế xác thực sao cho trạm đó có thể tin cậy và cấp cho tiến trình quyền truy cập thích hợp tới trạm.
Hội viên tới câu lạc bộ: Việc một hội viên chứng minh có giữ thẻ hội viên đối với câu lạc bộ có thể được xem như sự tổng quát hoá của kiểu “người sử dụng tới trạm”. Ở đây câu lạc bộ chỉ cần quan tâm đến kiểm tra tính hợp lệ của thẻ hội viên mà không cần thiết phải biết thêm thông tin như danh tính đúng của hội viên. Các giao thức nhận biết tri thức không và những sơ đồ chữ ký chống chối từ có thể hiện thực được kiểu kịch bản xác thực thực thể này.
3.  Quy ước chung
Chúng ta xác định một tập quy ước như sau:
Alice, Bob, Trent, Malice,...: Là tên thực thể, viết tắt là A, B, T, M,...
Alice g Bob: M: Alice gửi đến Bob thông báo M. {M}K: Bản mã của thông báo M khi dùng khoá K.
K, KAB, KAT, KA,..: Các khoá mật mã, trong đó KXY ký hiệu khoá được chia sẻ giữa các thực thể X và Y,còn KX ký hiệu khoá công khai của thực thể X.
N, NA,...: Là các “Số sử dụng một lần”. Chúng là những số ngẫu nhiên được lấy mẫu từ một không gian đủ lớn. NX được sinh ra bởi thực thể X.
TX: Tem thời gian được tạo ra bởi thực thể X.
sigA(M): Chữ ký số trên thông báo M được tạo ra bởi thực thể A.
4.  Những kỹ thuật xác thực cơ bản
Các kỹ thuật xác thực tương đối phong phú, sau đây là những kỹ thuật xác thực cơ bản:
4.1.  xác định tính tươi của thông báo và tính sống của thực thể
Việc xác định thông báo có tươi hay không là một phần cần thiết của xác thực nguồn gốc dữ liệu và cả trong trường hợp xác thực thực thể khi một bên quan tâm đến “hiện trạng sống” của bên liên lạc với mình. Bởi vậy những cơ chế thiết lập tính tươi của thông báo và tính sống của thực thể là những thành phần cơ bản nhất trong những giao thức xác thực.
Bây giờ chúng ta sẽ mô tả các cơ chế chuẩn và cơ bản để đạt được những chức năng này. Trong những mô tả sau đây, Alice sẽ được đặt vào vị trí của người yêu cầu thuộc tính (ví dụ, là tính “sống” của cô ta hay tính tươi của thông báo) và Bob ở vị trí của người kiểm tra thuộc tính yêu cầu. Giả thiết rằng Alice và Bob chia sẻ khoá bí mật KAB nếu cơ chế sử dụng những kỹ thuật mật mã đối xứng, hoặc Bob biết khoá công khai của Alice thông qua khung chứng nhận khoá công khai nếu cơ chế này sử dụng những kỹ thuật mật mã phi đối xứng.
Các cơ chế thách đố - giải đố
Trong cơ chế thách đố - giải đố, Bob là người kiểm tra. Giả sử NB ký hiệu số ngẫu nhiên do Bob sinh ra. Cơ chế làm tươi thông báo này có dạng tương tác sau đây:
1- Bob g Alice : NB;
2- Alice g Bob : gKAB (M,NB);
3- Bob giải đoạn mã và chấp thuận nếu anh ta tìm thấy NB và từ chối trong trường hợp ngược lại.
Ở đây việc truyền thông báo đầu tiên thường gọi là “thách đố” của Bob đối với Alice và bởi vậy việc truyền thông báo thứ hai được gọi là “giải đố” của Alice đối với Bob. Bob ở trong vị thế của người khởi xướng trong khi đó Alice ở trong vị thế của người trả lời.
Cơ chế này sử dụng kỹ thuật mật mã đối xứng. Nếu khoảng thời gian giữa thách đố và giải đố là đủ nhỏ chấp nhận được thì thông báo M được coi là tươi thực sự.
Ẩn sau cơ chế làm tươi thông báo này là sự tin tưởng rằng thao tác biến đổi mật mã của Alice phải được thực hiện sau khi cô ta nhận được số ngẫu nhiên của Bob. Bởi vì số ngẫu nhiên của Bob được lấy ngẫu nhiên từ một không gian đủ lớn và như vậy không ai có thể đoán trước được giá trị của nó trước khi Bob chọn .
Rõ ràng, nếu thuật toán lập mã trong cơ chế xác thực trên không cung cấp dịch vụ nguyên vẹn dữ liệu đúng đắn thì Bob không thể thiết lập được tính tươi của thông báo M.
Sự chuẩn hoá các cơ chế thách đố - giải đố
Trong tiêu chuẩn quốc tế ISO/IEC 9798-2: 1998  Công nghệ thông tin – Công nghệ an toàn – Xác thực thực thể - Phần 2: Các cơ chế sử dụng thuật toán mã hóa đối xứng  đã chuẩn hoá ba cơ chế thách đố - giải đố (được đưa ra cho đến nay) như những kiến trúc cơ bản đối với các cơ chế xác thực thực thể đơn phương. Sự chuẩn hoá đối với cơ chế nói trên được gọi là “giao thức xác thực đơn phương hai bước” và được mô tả như sau:
1. B g A: RB || Text1;
2. A g B: TokenAB.
với   TokenAB = Text3|| gKAB(RB||B||Text2).
Sau khi nhận được TokenAB, Bob giải mã nó và chấp nhận cuộc trao đổi nếu sự giải mã cho ra số ngẫu nhiên RB đúng đắn hoặc từ chối cuộc trao đổi đó trong trường hợp ngược lại.            
Từ đây về sau chúng ta sử dụng ký hiệu của tiêu chuẩn ISO/IEC 9798 để đặc tả giao thức. Trong đặc tả giao thức của Tiêu chuẩn này thì Text1, Text2 là những trường tuỳ chọn, dấu || ký hiệu nối xâu bít, còn RB là số ngẫu nhiên được sinh ra bởi Bob.
Tiêu chuẩn này mô tả cơ chế xác thực thực thể. Chính vì vậy việc sự bao hàm thông báo B là định danh của Bob thay cho thông báo M trong cơ chế thách đố – giải đố là rất quan trọng. Trong giao thức này Bob là chủ thể xác thực và vì thế mục tiêu là thiết lập hiện trạng sống của Bob.
Cơ chế tem thời gian:
Trong cơ chế tem thời gian, Alice liên kết mật mã thời gian hiện tại vào thông báo.
Giả sử TA ký hiệu tem thời gian được tạo ra bởi Alice khi sinh ra thông báo. Cơ chế xác định độ tươi thông báo này có dạng không tương tác sau đây:
1. Alice g Bob : gKAB (M, TA);
2. Bob giải đoạn mã và chấp thuận nếu TA hợp lệ, từ chối trong trường hợp ngược lại
Việc kiểm tra sự tính nguyên vẹn dữ liệu qua phép giải mã ở đây cũng cần được thực hiện. Sau khi giải mã, Bob so sánh TA với thời gian của mình. Nếu sự khác nhau về thời gian đủ nhỏ theo ứng dụng cho phép (theo suy nghĩ của Bob) thì thông báo M được xem là tươi.
Tem thời gian không cần thiết phải tương tác vì vậy thích hợp cho những ứng dụng một chiều, chẳng hạn thư điện tử. Sự không tiện lợi của cơ chế tem thời gian là nó đòi hỏi phải đồng bộ hoá đồng hồ thời gian và phải duy trì cơ chế ở trạng thái an toàn.
Trong kiến thiết giao thức cơ bản, số ngẫu nhiên và tem thời gian là những thành phần đặc biệt của thông báo. Chúng đóng vai trò nhận biết tính tươi của những thông báo khác được tích hợp mật mã với chúng. Chúng ta sẽ sử dụng khái niệm nhận biết tính tươi để nói đến số ngẫu nhiên và tem thời gian.
Sự chuẩn hoá các cơ chế tem thời gian:
ISO/IEC 9798 cũng chuẩn hoá những cơ chế tem thời gian cho các giao thức xác thực. Sự chuẩn hoá đối với cơ chế nêu trên được gọi là “Giao thức xác thực đơn phương một bước ISO khoá đối xứng” và  được mô tả như sau:
A g B: TokenAB;
với TokenAB = Text2 || gKAB (XA|| B || Text1);
Ở đây XA ký hiệu sự lựa chọn giữa sử dụng TA là tem thời gian và nA là số tuần tự.
Cơ chế số tuần tự cũng có hai nhược điểm. Thứ nhất, một tập thông tin trạng thái cần phải được duy trì đối với mỗi bên liên lạc tiềm tàng (hai bên phải duy trì số tuần tự đồng bộ, cập nhật trạng thái mới sau khi nhận). Điều này là khó khăn đối với những ứng dụng trong môi trường mơ, trong đó mỗi thực thể có thể liên lạc với nhiều thực thể khác. Thứ hai, việc quản lý, lưu giữ số tuần tự có thể là rất phức tạp khi có những sai sót trong liên lạc hoặc ngẫu nhiên hoặc chủ ý (chẳng hạn như tấn công từ chối dịch vụ).
Chúng ta nhớ lại rằng giao thức xác thực nên là không trạng thái: Một giao thức có trạng thái không thể vận hành đúng đắn trong môi trường phức tạp. Chính vì vậy, người ta không khuyến nghị sử dụng cơ chế số tuần tự mặc dù những cơ chế như vậy đã được chuẩn hoá theo ISO/IEC.
4.2.  Xác thực lẫn nhau:
Những cơ chế cơ bản đối với tính tươi của thông báo và tính sống của thực thể đã xem xét ở trên được gọi là “xác thực đơn phương”, có nghĩa là chỉ có một trong hai thực thể tham gia vào giao thức được xác thực. Trong xác thực lẫn nhau cả hai thực thể liên lạc đều được xác thực.
Tiêu chuẩn quốc tế ISO/IEC 9798-3: 1998  Công nghệ thông tin – Công nghệ an toàn – Xác thực thực thể - Phần 3: Các cơ chế sử dụng kỹ thuật chữ ký số đã chuẩn hoá một số cơ chế xác thực lẫn nhau. Cơ chế dựa trên chữ ký có tên “Giao thức xác thực lẫn nhau ba bước sử dụng khoá công khai ISO” sẽ được chỉ ra dưới đây. Chúng ta chọn cơ chế này để thể hiện những nhận thức sai cơ bản về xác thực lẫn nhau.
Người ta có thể coi xác thực lẫn nhau chỉ đơn giản là hai xác thực đơn phương. Tức là xác thực lẫn nhau có thể đạt được bằng cách áp dụng một trong những giao thức xác thực đơn phương cơ bản hai lần ở hai hướng ngược nhau mà thôi. Nhưng nói chung điều đó lại không đúng.
Quan hệ tinh tế giữa xác thực lẫn nhau và xác thực một phía đã không được hiểu rõ ràng từ trong giai đoạn đầu của quá trình chuẩn hoá ISO/IEC đối với giao thức dưới đây.
Giao thức xác thực lẫn nhau ba bước sử dụng khoá công khai ISO:
Giả thiết: A có chứng chỉ khoá công khai CertA;
B có chứng chỉ khoá công khai CertB;
Mục đích: Hai bên đạt được sự xác thực lẫn nhau.
1.  B g A: RB;
2.  A g B: CertA, TokenAB;
3.  B g A: CertB, TokenBA.
Trong đó:TokenAB = RA || RB || B || sigA(RA || RB || B);
TokenBA = RB || RA || A || sigB(RB || RA || A).
Tấn công của Wiener lên Giao thức xác thực lẫn nhau ba bước sử dụng khoá công khai ISO đã được đề xuất. Nó gây ra hậu quả là A nghĩ rằng B đã khởi xướng cuộc liên lạc và chấp nhận định danh của B. Nhưng thực ra B đã không khởi xướng cuộc liên lạc và hiện vẫn đang chờ để kết thúc cuộc liên lạc bắt đầu bởi Malice(“A”).
Giao thức xác thực nêu trên đã được xem xét lại sau khi tấn công Wiener xuất hiện. Phiên bản mới đã khắc phục được tấn công Wiener so với phiên bản trước. Trong đó A được chỉ thị hiển là phải duy trì trạng thái phù hợp với số ngẫu nhiên RB của B đến khi cuộc liên lạc hiện hành kết thúc.
4.3.  Xác thực liên quan đến bên thứ ba tin cậy :
Trong các kiến trúc cơ bản của giao thức xác thực được đưa ra ở trên, ta đã giả thiết rằng hai bên tham gia giao thức hoặc là đã chia sẻ kênh truyền an toàn trong trường hợp sử dụng các kỹ thuật mật mã đối xứng, hoặc biết khoá công khai của bên kia trong trường hợp sử dụng các kỹ thuật mật mã phi đối xứng.
Như vậy thì các bên liên lạc đã biết nhau rồi, họ còn cần thực hiện giao thức xác thực để làm gì? Câu trả lời đơn giản là họ cần làm tươi kênh an toàn giữa họ với nhau bằng cách khẳng định lại hiện trạng sống giữa họ với nhau. Câu trả lời khác tốt hơn là, các kiến trúc giao thức cơ bản này là cơ sở cho các giao thức xác thực dành cho những kiểu liên lạc chuẩn và tổng quát hơn trong môi trường hệ thống mở