Smart card remoting
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Ueno, Daiki
On a cloud computing environment it is often required to use a user's smartcard on a remote server. That is, insert a smart card locally (windows orlinux client), ssh to a server, and then utilize the smart card to 'sudo'application or to a TLS application, or to 'kinit' to obtain a kerberosticket. Other operating systems such as windows provide this functionality viaUSB-pass-through. The purpose of this talk, is to describe where we are, andwhat we provide for that problem.
 Hello and welcome to the security dev room. I hope everyone is ready for a talk on smart card forwarding by Daiki Ueno. Thank you. Welcome, I mean. So hello everyone. Can you hear? Okay, okay. So, yeah, I'm Daiki from Red Hat. I'm working in... Okay. So, yeah, yeah. Okay. So yes, so in this talk, I'll propose some somewhat different kind of use case of smart cards that I call remote in. So here is a gender. First, I'll quickly recap what are smart cards and how they are practically used and then show the new use cases that's called remote in 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, okay. So yeah. So smart cards are basically small computing device that can perform some crypt operations such as encryption or decryption or creation of digital signatures or verification with 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 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 kind of use authentication with certificate and also signature donation inside the card. So first application requests authentication to the system Palm service and then one of the Palm module requests the smart cards to send back the certificate and then Palm module verifies 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. So but it is only happens in a single computer system. So I'm proposing to use it in a 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 it is a 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 a digital signatures for some build artifacts in remote continuous integration server. So let's look into the implementation. So it's actually not so hard. It's consistent of three steps. First we define the protocol to serialize the smart card access and then somehow expose the protocol into some server and then forward the forwarded server into the remote system. That's all. So let's look into the protocol. Probably 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 the open and then call the functions defined in the library. So one of the examples of pksds11 API is this C find object in it. This takes three arguments and returns the status value. So in our implementation of serialization we just map into some byte sequences like this. So we assign some call ID to this function that is currently 26 and also sends a call ID to send some signature information. This is UAA. That means the first one is mapped to the U-long value and the second and third ones are combined into a single array of 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 the 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 overall the implementation it is resized in the p11kit project that is a portable library. It is available in various distributions such as the beyond federal, some kind of unilineaxi distributions. And that mainly provides access to the multiple pksds11 modules and it's also as sure as a multislet. 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. So there is a tool that is called p11 tool that is from Gunutielus that lists some attached smart cards like this. So it's take time because actual smart cards are inserted. It is slow. So there are eight tokens attached to this system. And last two tokens have authentication capabilities. So let's use the 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. Now the smart card is exported into the run user. So OpenSSH has the capability to forward the unique domain so get into the remote server. So it is an OpenSSH extension but it works. I'm currently running a virtual machine on the local host with port 1025. So let's log in. So 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 p-lebonekit client module. Then I can see the forwarded smart card here. So 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 local site or the remote site. It is the remote site unfortunately so we are seeking for the solution about it. So there are some future plans of this project. First the invocation of these commands are very complicated and maybe we need to integrate it in OpenSSH or some Windows clients. But 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 site and then some treatment in the local system in some kind of system in the disk. 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 in it. That's a good idea I think. Thank you. Any other questions? 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 format but actually this serialization format is currently already used in several cases. So maybe we should think about it, about those like JSON or something like that in some extensible way. Hi, I have such 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 that libraries valid or that's original version? Yes, there are basic version checks because the PKS-A3 API is standardized so there are some checks what capability is not supported or supported in the local server. But maybe we can add some mechanism to make sure the compatibility of the protocol somewhere. Any other question? Hi, there has been another project like this around two or three years ago which is called PKS-C11 Proxy which was basically implemented in Ock Hamill. I couldn't compile it ever. I didn't manage it but they addressed a similar problem. Maybe you can look at that. Thanks for the very good talk. We struggled a lot with chip cards where the PIN card reader is actually a physical reader like 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 optional path. Are there any best practice advice or any ways we can solve this can help us keep that PIN as close to the chip card and not travel far? I think it can be already bypassed to the input if there is hardware input 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. Hey, thanks for the talk. I was hoping to find some solution for our local development environment. We are 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 the 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 network manager that runs the system demo as a root user and it needs to access the user's smart cards that can only be accessed through the specified UID. I'm not very familiar with the Docker but there might be some way to tunnel the Unix domain so get inside the container. Does it answer the question? We have one more minute for questions. Any other questions? Okay, let's thank Dike again and we have a five minute break. Yep, very nice. And we start on time because the video will start on time.
 Hello and welcome to the security dev room.  I hope everyone is ready for a talk on smart card forwarding by Daiki Ueno.  Thank you.  Welcome, I mean.  So hello everyone.  Can you hear?  Okay, okay.  So, yeah, I'm Daiki from Red Hat.  I'm working in...  Okay.  So, yeah, yeah.  Okay.  So yes, so in this talk, I'll propose some somewhat different kind of use case of smart  cards that I call remote in.  So here is a gender.  First, I'll quickly recap what are smart cards and how they are practically used and then  show the new use cases that's called remote in 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, okay.  So yeah.  So smart cards are basically small computing device that can perform some crypt operations  such as encryption or decryption or creation of digital signatures or verification with  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 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 kind of use authentication with certificate  and also signature donation inside the card.  So first application requests authentication to the system Palm service and then one of  the Palm module requests the smart cards to send back the certificate and then Palm module  verifies 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.  So but it is only happens in a single computer system.  So I'm proposing to use it in a 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 it is a 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  a digital signatures for some build artifacts in remote continuous integration server.  So let's look into the implementation.  So it's actually not so hard.  It's consistent of three steps.  First we define the protocol to serialize the smart card access and then somehow expose  the protocol into some server and then forward the forwarded server into the remote system.  That's all.  So let's look into the protocol.  Probably 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 the open  and then call the functions defined in the library.  So one of the examples of pksds11 API is this C find object in it.  This takes three arguments and returns the status value.  So in our implementation of serialization we just map into some byte sequences like this.  So we assign some call ID to this function that is currently 26 and also sends a call  ID to send some signature information.  This is UAA.  That means the first one is mapped to the U-long value and the second and third ones are combined  into a single array of 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 the 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 overall the implementation it is resized in the p11kit project that is a portable library.  It is available in various distributions such as the beyond federal, some kind of unilineaxi  distributions.  And that mainly provides access to the multiple pksds11 modules and it's also as sure as  a multislet.  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.  So there is a tool that is called p11 tool that is from Gunutielus that lists some attached  smart cards like this.  So it's take time because actual smart cards are inserted.  It is slow.  So there are eight tokens attached to this system.  And last two tokens have authentication capabilities.  So let's use the 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.  Now the smart card is exported into the run user.  So OpenSSH has the capability to forward the unique domain so get into the remote server.  So it is an OpenSSH extension but it works.  I'm currently running a virtual machine on the local host with port 1025.  So let's log in.  So 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 p-lebonekit client module.  Then I can see the forwarded smart card here.  So 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 local site or the remote site.  It is the remote site unfortunately so we are seeking for the solution about it.  So there are some future plans of this project.  First the invocation of these commands are very complicated and maybe we need to integrate  it in OpenSSH or some Windows clients.  But 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 site and then some treatment  in the local system in some kind of system in the disk.  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 in it.  That's a good idea I think.  Thank you.  Any other questions?  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 format but actually this serialization format is  currently already used in several cases.  So maybe we should think about it, about those like JSON or something like that in some  extensible way.  Hi, I have such 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 that libraries valid or that's original version?  Yes, there are basic version checks because the PKS-A3 API is standardized so there are  some checks what capability is not supported or supported in the local server.  But maybe we can add some mechanism to make sure the compatibility of the protocol somewhere.  Any other question?  Hi, there has been another project like this around two or three years ago which is called  PKS-C11 Proxy which was basically implemented in Ock Hamill.  I couldn't compile it ever.  I didn't manage it but they addressed a similar problem.  Maybe you can look at that.  Thanks for the very good talk.  We struggled a lot with chip cards where the PIN card reader is actually a physical reader  like 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 optional path.  Are there any best practice advice or any ways we can solve this can help us keep that  PIN as close to the chip card and not travel far?  I think it can be already bypassed to the input if there is hardware input 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.  Hey, thanks for the talk.  I was hoping to find some solution for our local development environment.  We are 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 the 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 network manager that  runs the system demo as a root user and it needs to access the user's smart cards that  can only be accessed through the specified UID.  I'm not very familiar with the Docker but there might be some way to tunnel the Unix domain  so get inside the container.  Does it answer the question?  We have one more minute for questions.  Any other questions?  Okay, let's thank Dike again and we have a five minute break.  Yep, very nice.  And we start on time because the video will start on time.
Smart_card_forwarding_0_131.png Smart_card_forwarding_132_647.png Smart_card_forwarding_648_1715.png Smart_card_forwarding_1716_1787.png Smart_card_forwarding_1788_1967.png Smart_card_forwarding_1968_2051.png Smart_card_forwarding_2052_2183.png Smart_card_forwarding_2184_2327.png Smart_card_forwarding_2328_2399.png Smart_card_forwarding_2400_2447.png Smart_card_forwarding_2448_4391.png Smart_card_forwarding_4392_5423.png Smart_card_forwarding_5424_7055.png Smart_card_forwarding_7056_7799.png Smart_card_forwarding_7800_8303.png Smart_card_forwarding_8304_9071.png Smart_card_forwarding_9072_10163.png Smart_card_forwarding_10164_14351.png Smart_card_forwarding_14352_14495.png Smart_card_forwarding_14496_14603.png Smart_card_forwarding_14604_15287.png Smart_card_forwarding_15288_16199.png Smart_card_forwarding_16200_16319.png Smart_card_forwarding_16320_17219.png Smart_card_forwarding_17220_17579.png Smart_card_forwarding_17580_18863.png Smart_card_forwarding_18864_19523.png Smart_card_forwarding_19524_19847.png Smart_card_forwarding_19848_20291.png Smart_card_forwarding_20292_20411.png Smart_card_forwarding_20412_20999.png Smart_card_forwarding_21000_21059.png Smart_card_forwarding_21060_21659.png Smart_card_forwarding_21660_21731.png Smart_card_forwarding_21732_24791.png Smart_card_forwarding_24792_27911.png Smart_card_forwarding_27912_37619.png Smart_card_forwarding_37620_37733.png