Procesamiento EMV VisaNet Perú Área de Aplicaciones POS Lima 29 de Setiembre 2017 SETIEMBRE ÁREA DE APLICACIONES POS 1.

Presentación del tema: "Procesamiento EMV VisaNet Perú Área de Aplicaciones POS Lima 29 de Setiembre 2017 SETIEMBRE ÁREA DE APLICACIONES POS 1."— Transcripción de la presentación:

1 Procesamiento EMV VisaNet Perú Área de Aplicaciones POS Lima 29 de Setiembre 2017 SETIEMBRE - 2016ÁREA DE APLICACIONES POS 1

2 2 Introducción El presente documento tiene como finalidad dar una visión general sobre el procesamiento de transacciones con chip, de acuerdo al estándar EMV que cuentan los Kernel’s de los POS de Visanet Perú. Este documento permitirá dar un conocimiento mayor a este estándar y permitirá ser de utilidad para nuevos desarrollos en los terminales.

3 ¿Qué es el estándar EMV? 3 M E V Estándar de interoperabilidad de tarjetas IC (Integrated Circuit – Chip integrado) con Terminales Punto de Venta, para la autenticación de tarjetas de débito / crédito. Este estándar fue definido por las tres marcas que forman el nombre. Considerar que EuroPay, en el 2002, se fusionó con Mastercard International formando Mastercard Inc. Busca la sustitución de la captura de banda magnética con el fin de ofrecer algo más seguro. En las siguientes diapositivas se profundizará en el funcionamiento de la interacción entre el chip y el terminal punto de venta.

4 4 Los pasos básicos del flujo EMV 1.Inicialización de la aplicación del chip. 2.Lectura de datos de la aplicación del chip. 3.Restricciones para el procesamiento de la transacción. 1.Verificación de la versión de la aplicación 2.Control de uso de la aplicación 3.Verificación de la expiración de la aplicación 4.Verificación del Tarjetahabiente (cardholder) 5.Gestión de riesgos del terminal 1.Chequeo del límite de piso 2.Selección aleatoria de transacciones 3.Validación de cantidad de transacciones (ATC) 6.Análisis de las acciones del terminal 7.Análisis de las acciones de la tarjeta (revisión del concepto de criptograma AC) 8.Procesamiento de Scripts del Banco 9.Finalización

5 5 0. Inserción de la tarjeta y reconocimiento de la aplicación El terminal POS cuenta con un conjunto de aplicaciones que podrá soportar (definido por el AID – Application ID). Una tarjeta puede soportar más de una aplicación dentro del chip. En base a esto ocurre las siguientes casuísticas: 1.POS y Tarjeta no coinciden en alguna aplicación en común. AID’s de la TarjetaAID’ Soportadas por el Terminal Visa CréditoVisa Electron Visa InterlinkVisa Plus AID Banco FalabellaVisa Loyalty Puesto que no hay una aplicación en común, el terminal generará un Fallback, solicitando la lectura de la banda magnética. Dato adicional: AID: RID (Identificador de la Marca de la Tarjeta) + PIX (Identificador del Producto / Marca de Aceptación) -RID: Visa = A000000003 -PIX: Visa crédito / débito = 1010

6 6 2.POS y Tarjeta coinciden en una aplicación en común. 3.POS y Tarjeta tienen más de 1 aplicación en común. AID’s de la TarjetaAID’ Soportadas por el Terminal Visa CréditoVisa Electron Visa InterlinkVisa Crédito AID Banco FalabellaVisa Loyalty Puesto que hay una aplicación, el terminal realizará el flujo en base a esta aplicación en común. AID’s de la TarjetaAID’ Soportadas por el Terminal Visa Crédito Visa Interlink AID Banco FalabellaVisa Loyalty El POS mostrará en pantalla la opción al tarjetahabiente para utilizar una de las N aplicaciones posibles (todas las que coinciden).

7 7 1. Inicialización de la aplicación (1) GPO (Get Processing Options) Command (2) Return AIP y AFL (1)POS envía comando para obtener las opciones de procesamiento (tipo de validaciones online/offline, tipo de autenticaciones de tarjetahabientes, entre otros). (2)Tarjeta (IC) retorna dicha información en los tags 82 (Application Interchange Profile – AIP) y 94 (Application File Locator – AFL). El tag 82 (AIP) indica qué funciones soporta la tarjeta. El tag 94 (AFL) indica la ubicación de los archivos (conocidos como records – registros) que el POS deberá leer para poder ejecutar las funciones de la tarjeta). Un registro (record) es una función de la tarjeta. El terminal ejecuta el comando GPO (Get Processing Options) para obtener la información contenida en estos tags. Luego de que se seleccionara la aplicación que será ejecutada ocurre la primera etapa: TagsBit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1Bit 0 TSI00000000 TVR00000000 Estado de los TAGS

8 8 2. Lectura de los Datos de la Aplicación Con el AFL retornado al POS, el terminal realizará peticiones de lectura de registros de la tarjeta (read record command requests). Considerar por cada petición del POS, se recibe un registro de la tarjeta. Cada ubicación dentro del AFL tiene 4 bytes con la siguiente estructura: Byte 1Byte 2Byte 3Byte 4 SFI (Short File Indicator)1° registro a leerÚltimo registro por leer- Se hace referencia a un archivo de la tarjeta Primer record que el POS deberá solicitar Último record que el POS deberá solicitar Indica cuáles records dentro del rango (Byte 2 – Byte 3) están asociados a la autenticación de datos (data authentication). Ejemplo: 0E 01 03 02 -0E: SFI -Se realizará la petición de los records 01, 02 y 03. -El record 02 y 01 están asociados a la autenticación de los datos (data authentication).

9 9 2.1. Data Authentication Se ejecuta entre las fases de Lectura de datos de la aplicación y el Análisis de Acciones del Terminal. Con la obtención del AIP, se puede saber que Autenticación de Datos Offline (ODA) soporta la tarjeta.  Existen 3 tipos:  Combined Dynamic Data Authentication (CDA)  Dynanic Data Authentication (DDA)  Static Data Authentication (SDA) Considerar el siguiente flujo:  Si el terminal soporta CDA, se ejecutará el CDA.  Si no soporta CDA pero sí se soporta DDA, se ejecutará el DDA.  Si no se soporta ni el CDA ni DDA, se ejecutará el SDA.  Si no se soporta ninguno de los ODAS, el bit 8 del TVR, se setea en 1 (significado: “Offline Data Authentication was not performed”).  Revisar EMV Book 3 página 181 para más detalle de cada byte.  Si falla alguno de los ODA, se setean en 1 el byte dentro del TVR, asociado al determinado ODA fallido (CDA failed bit, DDA failed bit, SDA failed bit). Una vez finalizada esta fase, en el TSI el bit “Offline Data Authentication was performed” se pone en 1.

10 10 ¿Cómo funciona el SDA? Issuer (Banco) Datos estáticos de la tarjeta Datos cifrados Issuer Private Key Issuer Public Key Cifrado (Algoritmo HASH) Visa Private Key Visa Public Key Issuer Public Key Certification Paso 1: POS descifra el Issuer Public Key, mediante la decodificación del Issuer PK Certification con el Visa Public Key (Visa Public Key + Issuer PK Cert.  Issuer Public Key) Paso 2: El POS con el Issuer Public Key en su conocimiento, decodifica los datos cifrados para obtener los datos estáticos de la tarjeta. (Issuer Public Key + Datos Cifrados  Datos Estáticos de la tarjeta) Premisa: Si la decodificación fue exitosa, significa que los datos de la tarjeta no fueron alterados.

11 11 ¿Cómo funciona el SDA? Variables de la Tarjeta y las entidades 1.La tarjeta posee datos estáticos (por ejemplo: fecha de expiración). 2.Estos datos son cifrados en la tarjeta mediante el uso de un algoritmo HASH en conjunto con las llaves privadas (Issuer Private Key) de su banco. Estos datos cifrados se almacenan en la tarjeta. 3.Las llaves públicas del banco (Issuer Public Key) son cifradas (por protección) por la marca (VISA) utilizando el Private Key de la marca. Con este cifrado se genera el Issuer Public Key Certification. 4.El Public Key de la marca Visa es enviado a los adquirientes (por ejemplo: Visanet Perú) que los guardan en los POS. Flujo SDA: 1.En el flujo SDA, primero el POS necesita descifrar el Issuer Public Key. Para ello, con su Visa Public Key decodificará el Issuer Public Key Certification para obtener lo que desea. 2.Ya con el Issuer Public Key obtenido por el POS, este decodificará los datos cifrados de la tarjeta para obtener los datos estáticos. 3.Si esta decodificación es exitosa, significa que la tarjeta no ha sido alterada.

12 12 ¿Cómo funciona el DDA? Issuer (Banco) Datos estáticos de la tarjeta Datos cifrados Issuer Private Key Issuer Public Key Cifrado (Algoritmo HASH) Visa Private Key Visa Public Key Issuer Public Key Certification Paso 1: POS descifra el Issuer Public Key, mediante la decodificación del Issuer PK Certification con el Visa Public Key (Visa Public Key + Issuer PK Cert.  Issuer Public Key) Paso 3: El POS con el ICC Public Key en su conocimiento, decodifica los datos cifrados para obtener los datos estáticos de la tarjeta. (ICC Public Key + Datos Cifrados  Datos Estáticos de la tarjeta) Premisa: Si la decodificación fue exitosa, significa que los datos de la tarjeta no fueron alterados. ICC (Chip) ICC Private Key ICC Public Key Certification Paso 2: POS descifra el ICC Public Key, mediante la decodificación del ICC PK Certification con el Issuer Public Key (Issuer Public Key + ICC PK Cert.  ICC Public Key)

13 13 Variables de la Tarjeta y las entidades 1.La tarjeta posee datos estáticos (por ejemplo: fecha de expiración). 2.La tarjeta genera dinámicamente llaves privadas (ICC Private Key) para decodificar por transacción estos datos estáticos. 3.Estos datos son cifrados en la tarjeta mediante el uso de un algoritmo HASH en conjunto con las llaves privadas (ICC Private Key) del chip. Estos datos cifrados se almacenan en la tarjeta para la transacción. 4.Las llaves publicas el chip (ICC Public Key) son cifradas (por protección) por su banco utilizando el Private Key del banco. Con este cifrado se genera el ICC Public Key Certification. 5.Las llaves públicas del banco (Issuer Public Key) son cifradas (por protección) por la marca (VISA) utilizando el Private Key de la marca. Con este cifrado se genera el Issuer Public Key Certification. 6.El Public Key de la marca Visa es enviado a los adquirientes (por ejemplo: Visanet Perú) que los guardan en los POS. Flujo DDA: 1.En el flujo DDA, primero el POS necesita descifrar el Issuer Public Key. Para ello, con su Visa Public Key decodificará el Issuer Public Key Certification para obtener lo desea. 2.Ya con el Issuer Public Key obtenido por el POS, este decodificará el ICC Public Key utilizando el Issuer Public Key y el ICC Public Key Certification. 3.Con el ICC Public Key obtenido, se decodificará los datos cifrados para obtener los datos de la tarjeta. 4.Si esta decodificación es exitosa, significa que la tarjeta no ha sido alterada. ¿Cómo funciona el DDA?

14 14 ¿Cómo funciona el CDA? La funcionalidad del CDA es semejante al DDA, con la única diferencia que los datos cifrados de la tarjeta, son todos los datos de la transacción por completo. En el caso del DDA, solo se cifran ciertos datos estáticos.

15 15 3. Restricciones Procesamiento de la Tarjeta La tarjeta restringe determinadas transacciones por varias condiciones como el país o el tipo de servicio. Durante este proceso, se hacen 3 validaciones.  Si la versión de la aplicación de la tarjeta es la misma que la del terminal.  Si el tipo de transacción está permitida.  Si la tarjeta es válida y no expirada.

16 16 3.1. Validación de Application Version Number El número de la versión de la aplicación es determinado por el esquema de pago (payment scheme). Por ejemplo: VISA  Si la tarjeta no cuenta con un número de versión de aplicación, el terminal asume que si se hizo un match.  Si la tarjeta y el terminal tienen el mismo número de versión, la transacción continua como siempre.  Si no hay match, se pone el bit “ICC and terminal have different application versions” del TVR en 1. 3. Restricciones Procesamiento de la Tarjeta 3.2. Control de Uso de la Aplicación: Con este flujo se determina si la tarjeta (esto se realiza mediante la validación del tag AUC – 9F07):  Es válida para una transacción normal (domestic - nacional).  Es válida para una transacción internacional.  Es válida para una transacción nacional de mercancía.  Es válida para una transacción internacional de mercancía.  Es válida para una transacción nacional de servicios.  Es válida para una transacción internacional de servicios.  Es válida para ATM’s.  Es válida para otros terminales que no sean ATM’s.  Permite cashback nacional.  Permite cashback internacional. Si no está permitido para ninguna transacción, el bit “Requested service not allowed for card product” del TVR estará en 1.

17 17 3.3. Efectividad de la aplicación / Chequeo de la fecha de expiración: Si la fecha de efectividad de la tarjeta es posterior que la fecha actual, el bit “Application not yet effective” del TVR se pone en 1. Si la fecha de expiración de la tarjeta es anterior a la fecha actual, el bit “Expired Application” del TVR se pone en 1. Ambos datos son obtenidos en la fase de Lectura de los datos de la aplicación.

18 18 4. Verificación del Tarjetahabiente Los métodos de verificación (CVM – Cardholder Verification Methods) son los siguientes:  PIN online  PIN cifrado offline  PIN plano offline  Firma  No CVM Dependiendo de los resultados del procesamiento del método de autenticación se actualizan los bits correspondientes (ver EMV Book 3 – TVR) con los siguientes valores posibles:  Cardholder verification was not successful.  Unrecognized CVM.  PIN Try Limit exceeded.  PIN entry required and PIN pad not present or not Working.  Online PIN entered. Si este proceso culmina, el bit “Cardholder verification was performed” del TSI se pone en 1.

19 19 5. Gestión de Riesgos del Terminal Se busca proteger el sistema de pagos ante algún fraude. En los mejores casos, la autenticación online de la transacción es la mejor forma de prevenir fraudes. Para determinar si la transacción vaya online, el terminal valida 3 cosas:  Si la transacción está debajo del límite piso offline (offline floor limit).  Si la transacción actual fue seleccionada al azar para que se procese online.  Si la tarjeta no ha realizado transacciones online hace mucho tiempo. Terminado este proceso, el bit “Terminal risk management was performed” del TSI se pone en 1. 5.1. Floor Limit Checking Si el valor del monto de la transacción supera el limite de piso, el bit “Transaction exceeds floor limit” del TVR se pone en 1.

20 20 5.2. Random Transaction Selection Un terminal puede seleccionar de manera aleatoria la transacción para ir online. Si esto ocurre, el bit “Transaction selected randomly for online processing” del TVR se pone en 1. 5.3. Velocity Checking Si una misma tarjeta no ha transaccionado online por mucho tiempo, puede ser un indicador de fraude. Para ello, la tarjeta cuenta con dos tags: Lower Consecutive Offine Limit (LCOL) – 9F14 Upper Consecutive Offline Limit (UCOL) – 9F23 Para el inicio de este proceso se realiza lo siguiente: Primero el terminal solicitará a la tarjeta el ATC (9F36 - Application Transaction Counter – número de transacciones) y el registro del último ATC que tuvo la última transacción online. El ATC (X1) incrementa en 1 por cada transacción EMV realizada con una tarjeta. Ejemplo: ATC=20, equivale a 20 transacciones EMV con la tarjeta de Juan Perez. El registro del último ATC que tuvo trx online (Last Online ATC Register – X2) es el valor en la instancia de tiempo donde la última transacción fue online. Ejemplo: ATC=15, equivale que la transacción 15 fue la última trx online de la tarjeta de Juan Perez.

21 21 En base a estos datos se realizan los siguientes cálculos:  Si: X2 – X1 > LCOL  bit “Lower Consecutive limit exceeded” del TVR en 1.  Si: X2 – X1 > UCOL  bit “Upper Consecutive limit exceeded” del TVR en 1.  Si: X2 = 0  bit “New Card” del TVR en 1.

22 22 6. Terminal Action Analysis A estas alturas, varios bits del TVR han sido puestos en 0 o en 1. Con este tag se determinará, finalmente si la transacción se puede declinar o completar de manera offline o completar online (solicitando la autorización al banco). Considerar esta decisión como preliminar. Luego de la decisión del terminal, se solicitará a la tarjeta la confirmación de su decisión. Es posible que la tarjeta cambie su decisión (esto ocurre en la fase de card action analysis). Estas decisiones están en base a 3 tipos de códigos de acción (3 códigos del terminal y 3 códigos de la tarjeta): TAC (Terminal Action Code) / IAC (Issuer Action Code) DENIAL TAC (Terminal Action Code) / IAC (Issuer Action Code) ONLINE TAC (Terminal Action Code) / IAC (Issuer Action Code) DEFAULT El tamaño de cada uno es idéntico que el TVR (5 bytes).

23 23 DENIAL ACTION CODES Como primera fase del terminal action analysis, se validan si se “activa” algún código de acción para denegar la transacción actual. El procedimiento es el siguiente (esto aplica también para los ONLINE ACTION CODES y DEFAULT ACTION CODES): 1. Se hace una suma binaria (función OR) entre el IAC y el TAC, ambos DENIAL. 2. Se comparan byte por byte, bit por bit, del resultado con el TVR.

24 24 COMPARACIONES Si existe una coincidencia entre el TVR y el valor del resultado de la suma del IAC y el TAC denials, el terminal deberá declinar la transacción (solicitud generación de criptograma AAC). Si no hay ninguna coincidencia, el terminal deberá realizar la comparación entre los ONLINE ACTION CODES. ONLINE ACTION CODES Se debe ejecutar el mismo algoritmo como en el caso anterior, pero esta vez se utilizarán los Online Action Codes del chip (IAC) y del terminal (TAC). COMPARACIONES Si existe una coincidencia entre el TVR y el valor del resultado de la suma del IAC y el TAC online, el terminal solicitará a la tarjeta autorizar la transacción online (solicitud de generación del criptograma ARQC). Si no hay ninguna coincidencia, el terminal deberá realizar la solicitud a la tarjeta de una autorización offline (solicitud de generación de criptograma TC).

25 25 DEFAULT ACTION CODES En caso que el terminal requiera la aprobación online de la transacción pero no está habilitado para ello, el terminal deberá realizar el análisis de los default action codes con el TVR. Se debe ejecutar el mismo algoritmo como en el caso anterior, pero esta vez se utilizarán los Default Action Codes del chip (IAC) y del terminal (TAC). COMPARACIONES Si existe una coincidencia entre el TVR y el valor del resultado de la suma del IAC y el TAC default, el terminal solicitará a la tarjeta declinar la transacción (solicitud de generación del criptograma AAC). Si no hay ninguna coincidencia, el terminal deberá realizar la solicitud a la tarjeta de una autorización offline (solicitud de generación de criptograma TC).

26 26 6.1. Generación del Criptograma AC Independiente de la decisión del terminal, este solicita la confirmación de la tarjeta. Es posible que la tarjeta esté en desacuerdo con el terminal. Cuando el terminal requiere de una petición de autorización online, autorización offline y declinación offline hacia la tarjeta, este utiliza el comando GENERATE APPLICATION CRYPTOGRAM. Es con esta petición que se da inicio a la fase de card action analysis.

27 27 7. Card Action Analysis Se da inicio cuando el terminal solicita el primer criptograma (first GENERATE APPLICATION CRYPTOGRAM). En esta etapa, la tarjeta hace su propia gestión de riesgos (esto está fuera del contexto EMV, puesto que es único por banco). Al final, la tarjeta retorna el resultado al terminal. POSIBLES RESULTADOS: 1.Transacción aprobada offline: Transaction Certificate (TC)  el adquiriente necesita proveer el criptograma al banco (en una próxima transacción en línea) para que se capturen los fondos de la transacción. 2.Transacción declinada offline: Application Authentication Cryptogram (AAC)  se rechaza la transacción fuera de línea. 3.Transacción con petición de aprobación online: Authorization Request Cryptogram (ARQC)  Enviado al banco para la autorización de la transacción. Luego de terminar esta fase, el bit “Card risk management was performed” del TSI se pone en 1.

28 28 ¿Qué es un criptograma? Es un criptograma HASH, solo la tarjeta y el banco conocen las llaves para generar este criptograma. Decisión Offline u Online: Si el terminal recibe un TC o un AAC, la transacción culmina en fuera de línea. Si el terminal recibe un ARQC, la transacción se envía online al banco para la autorización.

29 29 ¿Cómo la tarjeta genera el criptograma ARQC? 1.La tarjeta al ser emitida, recibe en el chip un MDK (Master Derived Key) proporcionado por el banco. 2.Por cada tarjeta (variando por PAN), se genera un UDK (Unique Derived Key). Para la generación del UDK se necesitan los siguientes valores:  El MDK  El PAN  El PAN sequence number (tag 5F34): identifica y diferencia tarjetas que cuentan con el mismo PAN.  UDK Derivation Option: parámetro para la encriptación.  Key Parity: parámetro para la encriptación. EJEMPLO

30 30 4. Con el UDK, también llamado Session Key, la tarjeta aplica un algoritmo HASH para obtener un valor que es resultado de esta llave con los siguientes tags EMV obtenidos en la transacción.

31 31 EJEMPLO

32 32 ¿Cómo el banco valida el criptograma? 1. POS genera el ARQC. 2. POS en el campo 55 de la ISO 8583, envía el ARQC (ARQC 1). ARQC 1 3. El banco con los datos de la trama ISO8583 enviada por el Host, generará su propio criptograma (ARQC 2). 4. Si: ARQC1 = ARQC2 (continua con la validaciones adicionales) ARQC1 <> ARQC2 (rechazo de la transacción) 5. El banco generará un criptograma de respuesta (ARPC – Application Reponse Cryptogram)  inicio del Issuer Authentication (autenticación del banco). POSHOSTBANCO ARPC 6. POS envía el ARPC a la tarjeta. 7. La tarjeta con el ARPC, valida si el criptograma enviado corresponde a su banco.

33 33 ¿Qué es el Issuer Authentication? En determinadas casuísticas, es posible que en una transacción EMV que se solicitó autorización en línea, tenga una “autenticación bilateral”. Es decir, el banco valida el criptograma de la tarjeta y la tarjeta valida que el banco a quien se le envió el criptograma es realmente su banco. Para este segundo punto, el terminal, en caso reciba un ARPC y la tarjeta soporta el Issuer Authentication (se indica en el AIP), utiliza el comando EXTERNAL AUTHENTICATION, para que la tarjeta valide el ARPC. En caso la tarjeta soporta esta funcionalidad, el bit “Issuer authentication was performed” del TSI se pone en 1. En caso que la validación fue fallida, el bit “Issuer authentication failed” del TVR se pone en 1.

34 34 8. Procesamiento de Scripts del Banco En algunos casos, el banco envía a la tarjeta comandos en formatos de script para que esta ejecute funciones dentro de sí misma, por ejemplo:  Bloqueo de la aplicación de la tarjeta  Desbloqueo de la aplicación de la tarjeta  Bloqueo de la tarjeta (irreversible)  Cambio de PIN  Desbloqueo de PIN  Alteración de Límites y Contadores Offline (LCOL, UCOL). Estos scripts son enviados en la respuesta a la autorización online que se hizo con el emisor, y puedes ser ejecutados antes o incluso después de la segunda generación del criptograma AC. Si el script fue procesado, el bit “Script processing was performed” del TVR se pone en 1. Si el script falló después de la segunda generación del criptograma AC, el bit “Script processing failed after final GENERATE AC” del TVR se pone en 1. La segunda generación del AC se verá en la última fase.

35 35 9. Finalización Cuando la tarjeta recibe el ARPC, este tiene que validar si es correcta o no, luego de esta validación, el POS solicita la generación de un segundo criptograma AC. Solo es posible generar un TC (aprobación) o un AAC (denegación) en base a lo evaluado por la tarjeta con el ARPC recibido. En caso que la tarjeta genera un TC (aprobación), este TC se almacena para que sea enviado posteriormente en la siguiente transacción online. Esto se conocía como confirmaciones positivas, las cuales los POS actuales ya no envían al Host de Visanet. En caso que la tarjeta genera un AAC (denegación), este AAC se almacena para que sea enviado posteriormente en la siguiente transacción online. Estos envíos online de los criptogramas AAC son conocidos como confirmaciones negativas.

36 36 Bibliografía Step by Step: How does a EMV contact card payment work? https://www.quora.com/Step-by-step-How-does-a-EMV-contact-card-payment-work EMV Book 1 – 4 EMV Glossary https://www.level2kernel.com/emv-glossary.html EMV: A to Z (Terms and Definitions) https://www.firstdata.com/downloads/marketing-merchant/EMV-A-toZ.pdf