 Hallo og velkommen til The Security Dev Room. Jeg håper alle er klar til å snakke på Smart Card forverdingen av Daiki Ueno. Takk. Velkommen. Så hallo everyone. Kan du her? Ja. Ok, så ja, jeg er Daiki fra Etihad. Jeg er vekkende i... Ok. Så ja, jeg er... Ok. Så, ja, så i det her snakket jeg har prøver som et skjølgaunt utgave av smartcards som jeg heter remoteing. Så her er det skjølget. Nå skal jeg snart snakk opp hvem som er smart cards og hvordan de beror på sport�. Og så sørgere tabernes utgav som heter remoteing. and then look into the technical details of implementation. And if we have time, I'll show some demo, and then discuss the future plans of this project. So smart cards, maybe everyone knows what is smart card, but they can look in a different form factor, such as like usual banking cards or national ID cards, or it can be something like USB dongle, like USB sticks. And there are even software-only implementations, such as soft HSM. So in our terminology, they can be often called as tokens instead of smart cards. So smart cards are basically a small computing device that can perform some crypt operations, such as encryption or decryption, or creation of digital signatures, or verification of it. And also it provides some storage functions, such as certificate store, or it can also secretly store some private keys in there. So why in this age smart cards are still important? Because they can protect private keys inside the device itself, so it can prevent leakage of the private keys from the card to the local file system or running process. So that's because all the private key operations, such as decryption or signing can happen in the card itself, so it is very safe to use it, compared to using the local machine to compute some crypt operations. So this is a common use case of smart cards, that is a kind of user authentication with certificate, and also signature generation inside the card. So first application requests authentication to the system PAM service, and then one of the PAM modules requests the smart cards to send back the certificate, and then the PAM module verifies the certificate, and then it asks the smart card to sign some arbitrary data, and then verifies signature. So after all, it's the user authentication success. But it only happens in a single computer system, so I'm proposing to use it in cloud computing or remote settings, such as like this. So that is to allow some remote applications to use locally attached smart cards to authentication. So this is one use case of the smart remote use case, that is user authentication, but it can be also used as other uses, such as protecting private keys for remote TL server, or making digital signatures for some build artifacts in a remote continuous integration server. OK, so let's look into the implementation. So it's actually not so hard. It consists of three steps. First, we define the protocol to serialize smart card access, and then somehow expose the protocol into some server, and then forward it's server into the remote system. That's all. So let's look into the protocol. Most of you already know there is a standard C API called pksds11, that is a library API implemented by some smart card drivers, such as OpenSC or proprietary drivers. So basically usually those libraries can be used from the application by calling dlopen, and then call the functions defined in the library. So one of the examples of pksds11 API is this C find object init. It takes three arguments and returns the status value. So in our implementation of serialization, just maps into some byte sequences, like this. So we assign some call ID to this function, that is currently 26, and also send some signature information. This is UAA, which means the first one, each session is mapped to the U-long value, and the second, the third one, sorry, the second and third ones are combined into a single array over attribute struct. So yeah, like this. So it is very simple serialization form. So the complete implementation looks like this. The user starts the unique socket server in the local side, that bridges access to the smart card into the remote server. In the remote server, the system administrator installs the pksds11 client module, and then application can use it to access to the remote smart card. So over the implementation, it resides in the p11kit project, that is a portable library. It is available in various distributions, such as the beyond federal, some kind of new Linux distributions. That mainly provides access to the multiple pksds11 modules, and it's also assures a threat. And also it supports some URI, that identifies the pksds11 tokens, or some private keys or public keys on the smart cards. So it also supports some consistent, system-wide configuration pksds11 modules. So let's see the demo. I hope this will work. But there is a tool, that's called p11 tool, that is from GnuTLS, that lists some attached smart cards like this. So it's tech time, because actual smart cards are inserted. It is slow. Yeah, there are eight tokens attached to this system. Last two tokens have authentication capabilities. So let's use number six token. So I just specified the token with pksds11 URL right here. So then you see several public keys and private keys inside of it. So then forward this token into the remote server. So first I'll create some server. The smart card is exported into the run user some socket. Open SSH has the capability to forward the unix domain socket into the remote server. So it is an Open SSH extension, but it works. I'm currently running a virtual machine on the localhost with port 1025. So let's log in to it. Here I am on the different user ID. So by default this virtual machine doesn't have any token attached here. So there is only certificate store. So I now specified pdbunkit client module. Then I can see the forwarded smart card here. And even I can use it from sudo command like this. So it seems to work. It is only for the first time. Smart card authentication happens. So we can use this later invocation of sudo. Yes. The question is the pin entered in here is asked by the client's local side or the remote side, right? Yeah, it is the remote side unfortunately. So we are seeking for solution about it. So yes. So there is some. So yeah, basically there are some future plans of this project. So first the invocation of these commands are very complicated. And maybe we need to integrate it in OpenSSH or some Windows clients. And also more seamless integration with systemd. Would be possible, I guess. And as the question mentioned, there are some slight security implications, such as all the objects on the smart card can be visible in the remote side. I think it is not so secure. So we probably need to provide access control on it. And yeah, there are some operations that might not be useful in forwarding. So maybe we can disallow unused operations. And also pin input is currently on the remote side. It can be stolen by the malicious servers. So maybe we can introduce some kind of two-factor authentication that intercepts the pin input in the protocol level in the local force side. And then some treatment in the local system in some kind of, sorry, system pin dialog in the desktop. So also I'm thinking of some kind of protocol standardization in near future. Yes. So that's all. Questions? I have two questions. The first one is when you remotely enter the pin code for the smart card, I guess it's on the remote server, and then you negotiate it using the socket that you forwarded. Instead of using this forwarding socket, using the remote forwarding system in SSH, why not using the SSH agent forwarding? In SSH you can just do a forward agent, and then you can negotiate the PKE in the local and not the remote server. It could be another idea instead of using the remote dialog. That's a good idea, I think. So any other question? I'm wondering whether there's a good rationale for the serialization of the protocol, because it seems to be binary representation, custom made. But I suppose other people have done remote procedure calls before, and I guess they've done it differently. Can you explain why you chose to serialize it the way you did? Yes, we are actually considering other formats, but this serialization format is currently already used in several cases, so maybe we should think about it like Jason or something like that, in some extensible way. I have such a question. For example, if you implement a proper API for that library, and it will be stable, what if someone replaces that library with their own version, that it always, for example, returns incorrect result, but application thinks that it's correct. Do you have some checks for that library's valid, or that's the original version? Yes, there are basic version checks, because the PKS3 API is standardized, so there are some checks. What capability is not supported or supported in the local server? Yes, but maybe we can add some mechanism to make sure the compatibility of the protocol somewhere. Any other questions? There has been another project like this around two or three years ago, which is called PKS11 Proxy, which was basically implemented in Ockhammel, I couldn't compile it ever, I didn't manage it, but they addressed a similar problem, so maybe you can look at that. Another question? Thanks for the very good talk. We struggled a lot with chip cards, where the PIN card reader is actually a physical reader, common in medical and banking industry, and to force that the PIN is not entered through the keyboard, but through that keypad, because in software you have an optional path. Are there any best practice advice, or any ways we can help us keep that PIN as close to the chip card and not travel far? I think it can be already bypassed the PIN input, if there is hardware PIN part, but I have never tried it, but in the protocol level maybe the client side can decide whether to send or ask the PIN in the remote server, I guess. Hei, thanks for the talk. I was hoping to find some solution for our local development environment. We're using smart cards for accessing private key repositories in remote servers, and when I would want to move our building tools inside Docker containers, I'm not able to forward our smart cards into Docker containers. Do you know if your tool or something else exists for this kind of problem? I think another use case of this separation of the client server is the network manager that runs the system demo as a root user, and it needs to access the user's smart card that can only be accessed through the specified UID. I'm actually not very familiar with Docker, but there might be some way to tunnel the Unix domain socket inside the container. Does it answer a question? We have one more minute for questions. Any other question? Okay, let's thank Dike again, and we have a five minute break. The video takes from here to there. We start on time because the video will start on time.