Secure payments over VoIP calls in the cloud
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/61775 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023503 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Physical systemCloud computingArchitectureProcess capability indexDecision support systemInternettelefonieProcess capability indexRule of inferenceOpen sourceInformation securityStandard deviationCloud computingComputer architectureOrder (biology)Computer animation
01:27
Standard deviationInformation securityMemory cardPlastikkarteRule of inferenceProcess capability indexProcess (computing)Decision support systemAdditionComputer wormFormal verificationLevel (video gaming)EmailIntegrated development environmentOperations support systemSession Initiation ProtocolDisintegrationNP-hardArchitectureDefault (computer science)Database normalizationCodeExclusive orCloud computingComponent-based software engineeringComputer-generated imageryContinuous integrationSingle-precision floating-point formatCharge carrierFlow separationRouter (computing)Process (computing)EmailArrow of timeInstance (computer science)CASE <Informatik>HypermediaInformationMultiplication signOrder (biology)PlastikkarteIntegrated development environmentSystem callRule of inferenceInformation securityNumberSession Initiation ProtocolProcess capability indexVirtual machineComputer architectureOvalNormal (geometry)Personal identification numberCodeImplementationTouchscreenCloud computingDialerType theorySquare numberLevel (video gaming)Telecommunication1 (number)Memory cardDifferent (Kate Ryan album)Computer animation
10:18
World Wide Web ConsortiumMereologyOrder (biology)InformationService (economics)Process (computing)Descriptive statisticsCodeComputer animation
11:12
ArchitectureIntegerIntegrated development environmentProduct (business)Computer fileHard disk driveConfiguration spaceTouch typingEncryptionComputer animation
12:15
CodeRevision controlInstance (computer science)ArchitectureData managementInstance (computer science)Row (database)Charge carrierDirect numerical simulationComputer architectureProcess capability indexInternet service providerDecision theoryInformation securityFirewall (computing)System callSoftware testingProcess (computing)Data managementService (economics)CodeProcedural programmingMemory cardSession Initiation ProtocolPublic key certificateState of matterContext awarenessCodeToken ringNumberDialectComputer animation
16:51
1 (number)HypermediaComputer configurationCASE <Informatik>Session Initiation ProtocolProcess capability indexDifferent (Kate Ryan album)QuicksortComputer animation
18:47
Program flowchart
Transcript: English(auto-generated)
00:05
Ok, my name is Nuno, I've been around VoIP and RTC for the last, I think, 15 years, the last 10 more involved with open source, and, well, right now I'm working at TalkDesk,
00:23
which is a contact center, cloud driven company, and we are starting adopting more and more open source technology into the company, and, well, that's what also drives me. So my talk will be about secure pavements over VoIP calls in the cloud, it's something
00:43
that all contact centers probably need, and in order to do this we have to follow some rules and specifications, and let's dive into that. Ok, so I'll be telling you what PCI DSS is, what was the existing problem, and what was
01:06
the solution for our own implementation, the actual architecture of the solution, and our DSS, Payment Card Industry Data Security Standard, well, it's a standard
01:34
that was put up together by a bunch of companies like American Express, Discover,
01:43
MasterCard, Visa, etc. So they created a bunch of mandatory rules for the industry, and this is called the PCI Data Security Standard, and, well, in PCI lingo all business that process credit cards are referred as merchants, which is our case at TalkDesk,
02:05
and whenever we are big or small we have to follow these rules for credit card security. And basically there are very different levels for the merchants, the ones that process like
02:24
6 million transactions, whatever, so they are level 1, usually contact centers if they're not that big they end up in the levels 3 or 4.
02:41
Again, SAQs, so SAQs are self-assessment, questionary levels, so we have to kind of answer some questions to see where we fit, and basically since we are an electronic processing company we fit in under SAQA, and so no face-to-face merchants, everything
03:09
is done with e-commerce or telephone, so this is where we are at. So, the existing problem and solution, why we did something different.
03:24
So in order to do this kind of payments we were using some proprietary equipment like SPCs, etc., and everything in the end sometimes had some failures, there's the usage
03:43
of DTMFs on this a lot, at least for typing the credit card number we need to use DTMFs, but besides the credit card numbers itself we have also to use DTMFs to tell the partner that the actual partner, I will be speaking more about it later, the partner basically
04:08
needs to know when you want to have your channel secure for the actual customer be able to start typing the credit card information.
04:20
That was being done by the usage of PIN on the agent side, so the agent would basically use his dialer in the screen most of the times to type a PIN in order to engage with the PCI partner and if all went well the actual customer would be hearing a voice
04:43
telling him the call is now in a secure situation, you can follow up like typing the credit card. Most of the times this works but there are a lot of times that the DTMFs are not well recognized, sometimes the SBC failed completely because there was a need, I will be on that
05:08
later on again, but there was a need of transcoding the actual DTMF from the RTP to SIP infos in order to tell the partner about the actual DTMF, the number, and well
05:28
we also have a very hard time integrating the SBC world, the proprietary world with modern APIs in order to have more fluent scenarios.
05:44
The alternative, the solution, basically we decided to use Camellio and RTP engine for the new solution, it lets us have more easy to adapt and evolve, it's easy to integrate
06:00
with modern APIs, everything can be done with SIP and we will get into the actual architecture next. So about architecture, the PCI environment itself needs to be contained from whatever
06:23
you have in your void for normal calls, it has to be separate and contained, so in order to actually use payments, so the phone number that the customer uses to call and do a payment basically goes through a contained environment, in our case we are all in AWS,
06:47
so we have basically a separate account just for this, and for our new implementation we did everything with infrastructure as code and by doing CI CD we were able to deploy
07:05
without the need of like logging in to a machine or having SSH access or that kind of stuff. So about the actual architecture for this, so we have the actual carrier and we have
07:24
this CPAZ which are asterisk, can be cloud, a cloud provider like Twilio or Nexpo or single wire or whatever, and this secure router is what we call this new solution that
07:40
we developed, it's basically several possible instances of Camellio and RTP engine and there's in the top the PCI partner, this is the actual partner that processes the payments so we don't process and we don't touch the actual credit card data, and the way this
08:05
works is basically the call comes in from the carrier side, if it's an inbound one and it goes through like this, this is the media for the normal call without being still under the secure channel for payments, so the call comes in, it ends up in the
08:26
agent on this side and whenever the agent wants to, in this case this blue arrow here, it goes always through the PCI partner, the PCI partner injects a new header in
08:43
the SIP with a token, so the token comes back down here and it is extracted and it is sent to a smaller helper microservice that we have, this microserver basically then uses an internal API to tell the CPaaS and that the actual call that is coming in
09:05
as that token for starting the securization process in case of a payment needs to be done. So the signaling goes always through the PCI partner, the media goes from the carrier
09:21
to the CPaaS side without leaving, and whenever the agent on the CPaaS wants to start the secure process for starting a payment, basically he uses the token that was passed into his UI and that triggers, reinvites from the PCI partner down to our secure routers
09:49
and basically the media starts flowing through them for the actual time of the payment processing, so this is basically how this works. So this yellow square here means that we are
10:07
under a closed environment just for PCI, we have to follow that because rules imply that. And basically some snippets on the infrastructure as code for this, so we are using a bunch
10:26
of Terraform with Ansible in order to deploy everything automatically, sorry it doesn't read too much here, sorry about that. But here we are telling, in this part it's the dispatcher
10:45
that we are populating for Camellio, there's also some information about how the process of Camellio started, the certifies that are used for TLS, a lot of description for the services.
11:05
Would you put the previous one just a moment? Yeah, the one before, okay.
11:23
Here it's a small snippet of the Camellio config file itself, so in this case, sorry about that it's unreadable, but it's where the actual engage with RTP agent was happening, so we have a bunch of ciphers here that need to be used, but by using this and with
11:50
containerization, so the actual Camellio is put inside the container, the container is then launched, mapping an external volume with some defaults, and that way we don't need basically to
12:08
human touch this deployment. Okay, another important part, we rely a lot on DNS, so we use NAPTR records with SRVs for
12:26
basically describe where our instances are, so the PCI partner uses DNS to speak to us, the carrier the same thing, the CPA is the same thing, and by doing this and without need to be
12:42
stateful for anything, we can basically launch the number of instances that we want. Since we are using AWS and we need basically this kind of deploys to happen in several regions of the world, we also do that very easily by using this approach, and as I say here,
13:03
R coding is almost not a great thing, but in this case, as I say around here, it gives the rigidity that we need to fulfill the requirements and the standards, and it proved to work well.
13:26
So, how it actually works, this is a screenshot of the UI that the agent sees, so basically these are what we call context cards for the agent, one of the context cards gives the PCI token that
13:44
comes in the SIP and then it's extracted in Camellio and sent to our internal API for the contact center layer, and it appears there, so whenever the agent needs to start the payment, he just needs to press a button that will use that token
14:06
and the call will be in what is known as a secure state for payment. Okay, wrapping up.
14:22
So, something about the certification process and the audit, every entity that wants to be processing payments needs to go through this every year, the certification needs to be renewed every year, and the one that we did more recently was last November, and the year before
14:48
still was on the old proprietary stuff, there were several small issues that kept open from last year to this year, and by using the new implementation, we basically passed everything,
15:09
the solution is put under test for pen tests, it's something that is in the runbook of the audit, so everything passed, I didn't mention, but the actual infrastructure
15:24
s code also configures the firewalls in AWS, so we just have the ports that we need to work with open, and we have also ACLs for the PCI partners that we are using to
15:43
process payments, the carriers, the same thing, so that's the way we did it, and in the end, basically the audit identified some strengths for this, so they told there was excellent management and procedures in this, we adopted a risk treatment approach,
16:03
and we always used certified service providers for carriers and for the partners that do the payments, they also need to be PCI certified. About the carriers, this architecture basically
16:22
lets you use any carrier you want, but you have to kind of decide if you really trust some of the carriers that you put into this, because basically if you integrate this with a PBX or so from a client, let's say, it can always intercept the call on its side, and that could not be good,
16:49
so yeah, that was it, and that's what I add, thank you. Okay, I guess you, any questions?
17:10
There's one over there. So do you find that your solution's been built around one particular
17:23
provider, or is the solution that you've built sort of, you bet that it's really worked with other ones as well, did they follow the same paradigm? Yeah, most, there's small differences when you basically switch a PCI partner that processes the payment, right? There are small differences between them, but we basically worked with three, four partners for this, and
17:48
they most use SIP. If they use only SIP, that's the best option. The one that I presented here, it's the most complex one because it involves re-invite, sending media to them during the actual
18:04
payment process, but it will depend, so sometimes it's more direct and easy. The case that I spoke about was the most complex one that involved media redirects and that kind of stuff.
18:23
Any partner? Not really, I guess all of them, if you, I really don't want to say names here, but if you basically look for the most relevant ones in the internet, they are the ones that will work under this, fine. Thank you. Yep, thanks.